BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Debating the Merits of Pair Programming

Debating the Merits of 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.

Rate this Article

Adoption
Style

BT