Pair Programming Benefits

Intro

Pair programming can be defined as two (or more) engineers working together using a single computer. There is a division of responsibilities between the two engineers, with one having control of the computer and actively making changes to the code base. At the same time, the other considers more significant questions of the implementation.

History

Evidence suggests that pair programming may be as old as the computer. The women responsible for programming ENIAC circa 1943 worked in pairs. Pair programming's more modern definition and use date to the Chrysler Comprehensive Compensation or C3 project in the mid-1990s, which spawned the agile framework known as Xtreme Programming. XP mandated the use of several software engineering practices, such as continuous integration, test-driven development, and refactoring, in addition to pair programming.

Benefits

Studies done on pair programming suggest that a pair writes approximately 15% less code than two developers working separately. However, the pair will produce 50% fewer bugs in their code. This reduction is achieved through separating concerns (tactical vs. strategic), which is impossible for a single person to do. A reduction in rework (bug fixing) can play a significant role in creating better flow and, most importantly, better predictability.

Building Trust

Pair programming is an excellent way to quickly build trust within a team. Direct exposure to your pair's coding practices, thought processes and design decisions creates an awareness of that person's competence and the degree to which you can trust that you have a shared understanding of the code under development

Knowledge Sharing

Knowledge sharing is one of the least disputed benefits of pairing. Pairing is an opportunity to spread the knowledge of the domain as well as the technology and will prevent the development of silos of knowledge.

Reflection

Communication during a pair programming session must occur by discussing the problem and its solution. Saying and explaining things aloud allows one to reflect on whether there is a shared understanding of the problem and the solution. Where a difference in opinion exists between the pair, this discussion can correct any misinterpretation of the requirements and lead to better solutions.

Keeping focus

Pair programming is an intense experience that reduces the opportunities to get distracted as the focus is on writing the code and doesn't allow either pair to, for example, check their email or get distracted in some other way. This focus will result in fewer errors caused by losing the thread of what you're trying to achieve in your code.

Code review on-the-go

Inspection of code review is a significant factor in reducing the incidence of bugs. Getting fresh eyes to examine the code comes at the cost of losing context.

Firstly, let's address the contrasting pattern for code inspection that is common among developers: the use of Pull Requests (PRs). Pull requests were a pattern that emerged in open-source software (OSS) development practices. In order to maintain a high level of code quality, code inspection is recognised as a major contributor to achieving that quality. However, in the context of an OSS project, there is usually a core team that maintains and extends the code base and a bigger community that is made up of incidental contributors.

In order to maintain control over the quality of their project, the rights to commit code to the main code branch had to be restricted to the core contributors. But in order to leverage the contribution of the community the pull request process was created. All changes made by non-core members are sent to the core contributors as a pull request which contains the code that has been changed together with a message explaining the context and reason for the change. This is then reviewed and there may be a process of discussion and modification before the PR is approved and merged into the main code line.

This is an effective system to maintain code quality in a low-trust environment where there may be limited opportunities to develop relationships and build trust with a potentially vast set of potential contributors.

In the context of a small team all working on a single project or code base, the use of pull requests is an anti-pattern and creates waste in the system by introducing wait time while the code in the pull requests awaits the availability of the designated code reviewers.

When reviewing pull requests, the author is at pains to communicate the context of the change through their commit message, which is much less effective than having the reviewer be a part of the development process. This commit message is a form of written documentation and it is the least rich method for conveying information. It does allow for a limited form of interaction usually via written discussion so there is an element of interactivity, assuming the reviewer and commiter engage in discussion before accepting or rejecting the pull request.

Other dynamics at play in the review process can result in less effective outcomes, such as the coder deferring decisions and improvements in the implicit belief that the review process will identify those required changes. On the other hand, the reviewer may implicitly trust the author's diligence, resulting in a superficial review of the PR. Pair programming avoids both these pitfalls.

Collective Code Ownership

Consistent pairing ensures that at least two people touch or see every line of code. This increases the chances that anyone on the team feels comfortable changing the code almost anywhere. It also makes the code base more consistent than it would be with single coders only. A critical element of this is that pairs must be diverse in their choice of pairing partners and not consistently pairing with the same person. This collective code ownership only emerges when there is promiscuous [airing practiced.

Fast on-boarding of new team members

Since pairing facilitates knowledge sharing, new joiners can learn the code base in a safe environment where they are unlikely to make mistakes, reducing the risk of adding a new team member.

Summary

My hope is that by using the points above it should be possible to create a persuasive argument to a manager, team lead, fellow coder or product owner/manager of the potential benefits that can arise when a team adopts pair programming as a standard engineering practice. For more details on how to go about introducing Pair Programming have a look at the accompanying blog post here.