Pair programming appears to be the most controversial of all the Extreme Programming (XP) practices. It invokes such a violent emotional response in some people that they quickly dismiss all of XP just because of this one practice.

Let me start by saying that I’ve done pair programming on software development teams and it has worked really well for me. I freely admit that it doesn’t work for everyone or in every situation however when it does work, it is the most effective form of peer review that I’ve ever used.

Laurie Williams of North Carolina State University has done extensive research into pair programming and has published her findings at PairProgramming.com. She has also written the book Pair Programming Illuminated with Robert Kessler. If you are interested in seeing actual research into this practice then I’d strongly recommend reading Laurie’s work.

Lets look at why this practice is so controversial.

The benefits of pair programming are significant. Overall development time is reduced and quality is higher. Additionally, teams doing pair programming tend to have more fun than teams working individually. People who have done pair programming when it worked well are strong advocates for the practice as they’ve seen first hand what is possible.

The biggest downside to pair programming is that it can push people well outside their comfort zones. I have often heard comments like “if they make me pair, I’ll quit”. This is an understandable fear reaction to something that is outside our comfort zone. Pair programming cannot be effectively mandated for exactly this reason. If the team is reacting out of fear then you won’t get any of the benefits of the pairing.

Another downside to pair programming that doesn’t get discussed as often is that it is tiring work. After a day of pairing, the team is usually exhausted.

I’ve also seen problems where there is a personality clash between programmers. I coached one team where I had two otherwise excellent programmers who couldn’t be paired with each other because of a personality clash. Either one could pair with anyone else on the team but they couldn’t be put together.

One common myth about pair programming is that it will take twice as long to complete a certain amount of functionality. In my experience (and the research backs this up), a pair will take longer to write the initial code but will spend less time debugging as the code will have significantly fewer defects. When the total developer time is measured, it actually turns out that pairs are more effective than individuals.

To be perfectly honest, I didn’t believe this claim myself until I actually tried it. Now I’ve seen the results first hand.

One nice side effect of pairing is that you are continually cross training the team. Over time, everyone will learn all parts of the application and therefore the team will be less susceptible to staffing changes.

If your team is open to the idea of pair programming then you can get some significant benefits from this practice. Be aware however, that mandating the use of pair programming can be disastrous if the team is not receptive.

Affiliated Promotions: