Pair programming = project reliability

What do you do if you want to have a reliable system? You make sure you have redundancy: More than one component can do a certain job. You back up you valuable data to a separate system. You have two servers to provide your critical service, in case on fails. Yet, many projects have no plan for the inevitable absence of people with critical knowledge.

We practice pair programming to get redundancy. This manifests itself in many ways:

  • When someone is sick, on vacation or leaves the project (to become a doctor, say), the project doesn’t suffer. Or rather, it doesn’t suffer as much. We do get less work done if fewer people are present, of course. And many of our developers have areas where everyone loves to get their help.
  • We can add new people to the team. Learning how the system works is just a matter of pair programming as part of the normal rotation.
  • We are very adaptive to varying focus at different times in the project. If we had someone who could only work with, say, databases, he wouldn’t have much to do at some times, and too much to do at other times. With pair programming, we still have people who’re especially good in some areas, but everyone can help out with whatever needs doing.
  • No parts of the code are off-limits. As every commit of the code is written by two people, no one person has the right to block changes to “his” code. Anyone can make the changes that they need to complete their current task as good as they can.
  • The team is working with fewer tasks at a time. As teams grow in size, there can be a lot of different things happening at the same time. This both increases the chances that people will step on each other’s toes (that is, work on the same source code files) and increases the amount of “Work in progress” at any one time. Pair programming effectively halves the amount of work in progress.
  • Everyone has a understanding of the whole system. During planning and design discussions, everyone can contribute. Instead of focusing on technical components and subsystems, the discussion is about how to solve the user story as a whole.

Some studies focuses on the impact of pair programming on efficiency, quality, progress, or even focus. I think it’s much more interesting to see how pair programming changes the dynamic of the team. From a group of individuals, we form teams where everyone is appreciated as a contributor. Everyone has their individual strengths, but more importantly, everyone has the same goal in mind: The success of the team.

Comments:

Patrick Kua - Feb 7, 2011

Hi Johannes,

I agree that when teams pair program, it really changes the dynamics of the team. I think it really helps with the XP Practice of Collective Code Ownership as well. Nice blog post

[Geir Amsjo] - Feb 4, 2011

Thank you for sharing this insight, Johannes! If all these 6 benefits are gained we should all promote pair programming actively. It would be great to have research evidence of course, but these effects are extremely hard to investigate / measure scientifically…

[Matt] - Feb 4, 2011

There is plenty of research out there.

Johannes Brodwall - Feb 5, 2011

Hi, Matt

Did you see my previous blog post? /2011/02/02/pair-programming-research-misses-the-most-important-point/

What studies did I miss? (Or what did I miss about these studies?)