Debating the Merits of Pair Programming

| by Kurt Christensen Follow 0 Followers on Jan 10, 2007. Estimated reading time: 2 minutes |

A note to our readers: You asked so we have developed a set of features that allow you to reduce the noise: you can get email and web notifications for topics you are interested in. Learn more about our new features.

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 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.

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

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.

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.

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.

Re: An interesting perspective by Chris Wilkes doesn't look like a real site to me -- appears to be a parked domain.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

4 Discuss

Login to InfoQ to interact with what matters most to you.

Recover your password...


Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.


More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.


Stay up-to-date

Set up your notifications and don't miss out on content that matters to you