I got a few angry and scolding comments on my last post on pair programming. Let me address each of the issues in turn:
- Programmers are not lazy – Rather, they are no more or less lazy than any other type of worker. Why do the peak usage times of most web sites, including Facebook and the like, coincide with business hours? You can look at the studies that reinforce this finding, but those traffic graphs speak volumes. Workers — developers included — that pair, spend less time on personal stuff than those that don’t.
- Nobody ever gets hit by a bus – True, but people do leave projects. Maybe the whole bus (or Pie Truck, if you prefer) is a read herring. The real issue isn’t developers leaving a project. It’s that you have less flexibility when one developer knows a piece of the code and the other doesn’t. I can’t double down on a part of the code that needs more resources, since then I’m in Mythical Man Month land and am throwing gasoline on the fire.
- Nobody can prove that pairs are more productive – There are studies pro and con on this. I can speak from experience. I’ve been on a number of agile projects that did not use pair programming. We had a good history on what the velocity for each iteration was. We changed to pair programming and got anywhere from a 30% to 50% increase in velocity going forward, along with a large decrease in bug reports per iteration. That’s pretty convincing.
It’s easy for folks to misunderstand pair programming and to dismiss it as useless, weird or wasteful. It’s one of the first things that gets ditched when the going gets tough, yet it’s one of the most important, along with TDD. That’s why I wanted to make as strong of a statement as possible in favor of pair programming and against singleton programming.
