Pair programming: A Developer’s Perspective

Of the myriad Agile software development practices, Pair programming is one that has never failed to fascinate me with its effectiveness and simplicity.

Pair programming, as the name implies, requires TWO developers to work on a single task or story. When adopted as the default mode of operation, an organization must be prepared to pay more upfront (in terms of man-hour costs) compared to traditional models of software development in which only one developer is needed per story. The real question is: Can this be justified so that stakeholders are convinced?

On a current product for which the team has the luxury of indulging in pair programming and Test-Driven Development as the default mode of operation, I observed that pair programming has brought about a number of benefits.

Ongoing development is never stopped because somebody is not around

There is almost zero downtime in day-to-day development for stories. On a regular working day, it is incredibly rare for both programmers paired on a story to take leave at the same time. If one developer should go on leave, the remaining developer could always easily pair up with another developer in the team to continue work without ever losing the context. This mitigates knowledge loss and reduces dependency on any single employee.

Code produced is more robust

Features are less likely to break downstream due to edge cases (whether during the QA phase or in staging/production). On the current project, uncaught downstream issues, particularly those in production, are expensive to fix as personnel would have to be activated. In this case, pair programming moves manpower costs upstream while improving the application’s robustness. If you are in the finance/telco space, this might be an important consideration since downtime frequently translates to potential penalties from the regulatory authorities.

Onboarding time is significantly reduced

By pairing an expert with a novice (in terms of system knowledge), pair programming provides an appropriate setting where the novice can ask questions easily and gain hands-on experience faster. By encouraging human interaction through swapping of pairs, the newcomer will also blend into the team much quicker compared to solo development.

Good team practices can be enforced

Having developers frequently rotated across different pairs helps to encourage the adoption of important practices like TDD, proper coding standards and version control. Shared responsibility of code commits also results in code that stands up to scrutiny since lazy coding is usually caught during pairing.

Potential pitfalls

While pair programming might bring about the above-mentioned benefits, it is important to note that it does come with its caveats and should not be adopted blindly.

Increased development time on some stories

Stakeholders, sponsors and development teams need to be aware that pair programming does not translate to increased team velocity. In fact, the implementation might sometimes take longer due to the frequent discussions that take place between pairing developers to arrive at a suitable code implementation.

Pairing when not necessary

There are scenarios when pair programming might not be optimal. For instance, while working on complex technical spikes, pairing might become a distraction when a focused investigation into the codebase is required. Conversely, pairing is overkill on low-complexity stories that are known to only require minor changes.

Developer stickiness

Effective pairing has the side effect of developers forming strong bonds with each other. As a result, same developer pairs would end up working on multiple stories consecutively if a rotation is not practised. Unrotated pairs have the tendency to develop a tunnel vision which reduces the effectiveness of pair programming. Developers should make it a point to switch pairing partners regularly.

Incorrect pairing dynamics

It’s easy for expert-novice pairings to end up becoming teacher-student relationships. A teacher-student pairing assumes that the student is only present to learn and practise, rather than to produce actual deliverable work. For instance, a ‘teacher’ might constantly rework the student’s code as part of the ‘teaching’ process, or worse still, the ‘teacher’ performs all the coding while the student only takes notes. In such scenarios, fellow developers in the team should step in and offer to switch pairing at the earliest opportunity.

______________________________________________________________________________________________________

Pair programming, as with other XP practices, is not a magical pill that will transform team dynamics or software quality overnight. Teams adopting pair programming for the first time might want to introduce it gradually by applying it to more complex development stories. Pair programming promotes the Agile principle of favouring face-to-face conversation and for engineering teams looking to achieve technical excellence, pair programming is definitely something worth considering.