Debating the Merits of Pair Programming

Posted by Kurt Christensen on Jan 10, 2007

Sections

Process & Practices

Topics

Agile ,

Agile Techniques

Tags

Pair Programming

Mike Arace recently wrote a piece describing his aversion to pair programming:

Talented people chafe at having to justify everything they do to another person. Programmers rely on a lot of intuition and experience, and needing to put that into words for people who don’t “get it” is extremely tiring.

Mike has been writing about his team's transition to an agile development process, and so far has had a generally positive experience, with the exception of pair programming:

I think pair programming is going to take a lot of work for me to digest, if for no other reason than it seems to promote mediocrity. The sheer energy needed to convince a whole team of people on how to design a simple login function (for instance) seems to fly in the face of what Agile is purported to fix: Overburdened design discussions.

The difficulties of introducing pair programming have been discussed before. So why even try? Kent Beck explains the rationale for pair programming in his book Extreme Programming Explained:

...[a] powerful feature of pair programming is that some of the practices wouldn't work without it. Under stress, people revert. They will skip writing tests. They will put off refactoring. They will avoid integrating. With your partner watching, though, chances are that even if you feel like blowing off one of these practices, your partner won't..

This may be true, but from a scientific viewpoint, the quantitative evidence is hardly overwhelming. There have been a variety of papers published which attempt to provide evidence for the benefits of pair programming. But the quality of this research was called into question on hacknot.info in an essay from 2004:

What I want to know is - why, as a community, do software developers eat this stuff up so uncritically? Why are there so many people, including Williams herself, quoting this experiment and its conclusions as if they were some sort of vindication of pair programming, when they are in fact meaningless? Where are the critical examinations of her experimental method?

The essay provides a detailed criticism of the research methods used, but they all essentially boil down to a single issue: the researchers conducting pair programming experiments are computer scientists and not social scientists. What the agile development community lacks are large-scale studies performed by unbiased researchers who are capable of effectively conducting experiments in the social sciences. Until then, any debates about the costs and benefits of pair programming will rely largely on anecdotal evidence.

1. Back to top

   An interesting perspective

   by John Rusk

   I've found this to be informative. It is a presentation from an XP confrence about an XP team which did not use pair programming. Their reasons why are informative - basically their view is that the value of pairing is proportional to the cost of fixing production defects. www.agiledevelopmentconference.com/files/XR1-3.pdf

   Reply

2. Back to top

   Pair Rotation and Intagibles

   by Greg Willits

   I'm new to XP/pairing, and currently only interface with a team doing it (not done it myself), but what I like about it, from the perspective of people doing it on my behalf, comes not only from the pairing itself, but pair rotation. In addition to the Beck quote in the article, I think having multiple people familiar with a majority of the code is a valid benefit. Pairing provides that itself, but pair rotation takes it even further. I believe it reduces "key-man" risk, and when there needs to be debate about design, I see that debate have meaning grounded in familiarity with the code and not just theoretical positions debated that often end up useless because reality made it all moot.
   
   It seems to me pairing should consider the individual's skills and the stories to be worked on. Match experienced/inexperienced people in pairs give the inexperienced folks a chance to stretch, but also give the experienced pairs a chance to work together to tackle the stories where their experience can be let loose on a problem that needs some creativity, or shouldn't be burdened by trying to keep someone with less experience up to speed. Here again, I see rotation as being a valuable aspect of pairing.
   
   I can see pairing be very difficult to quantify. I've worked in engineering, software, and marketing in my career, and there are classic debates on ROI for certain marketing principles/functions not the least of which is advertising. These tend to be things that long term studies provide more clarity on the benefits. I can see pairing being one of those things where the benefits are largely intangible which by definition is very difficult to correlate to value.
   
   I instinctively see the advantages of pairing, but I'd be hard pressed to be able to prove its value logically or economically to someoe who just didn't get it.

   Reply

3. Back to top

   Result = union | intersection

   by Niels Bech Nielsen

   I disagree with Mike on his negativity because it is about benefitting from two peoples combined knowledge and foreseeability, and not about mediocrity and negotiating a common denominator. Management should look careful at when not using PP, and how the teams should manage themselves.
   
   I concur on the fact that there is nothing like social science in computer science. I have seen too many decisions based on too fragile a foundation within research as within industry, but I do hope at least research will pull themselves up by the reims.

   Reply

4. Back to top

   Re: An interesting perspective

   by Chris Wilkes

   www.agiledevelopmentconference.com/ doesn't look like a real site to me -- appears to be a parked domain.

   Reply

• Older >