soylent green is people. so is software

I did a presentation on pair programming at a client a while back and it caused me to reflect a bit on the virtues of pairing. During my research, as is often the case for me, I found someone that articulated the benefits (and concerns) far better than I could. He may not have had pair programming in mind, but it is amazingly apt:

"Only if the various principles - names, definitions, intimations and perceptions - are laboriously tested and rubbed one against the other in a reconciliatory tone, without ill will during the discussion, only then will insight and reason radiate forth in each case, and achieve what is for man the highest possible force..." - Plato

Despite the somewhat sexist use of the word 'man' as a synonym the human race, Plato has done a good job here of describing the process of argument and some of the things to watch out for. The section that resonated most with me was the notion of perceptions being "laboriously tested and rubbed one against the other". This is where the true advantage of pair programming comes to the fore. By rubbing one idea against another, new ideas are born... is there a euphemism there? Anyway, the point is that you may start out with a couple of different ideas, but the process of discussion will often modify these ideas, combine them, or spawn completely new ideas. I've even had misunderstandings inspire orthogonal solutions. One participant will explain an idea, and the second participant will misunderstand, but try to build on their (mis) understanding, sometimes even coming up with a superior design.

But you don't need to take my word for it. A study undertaken by Alistair Cockburn and Laurie Williams highlighted the benefits of pair programming. During their research, they found that pair programming improves design quality, reduces defects, reduces staffing risk, enhances technical skills through knowledge transfer and improves team communication. It costs about 15% more in development time (not double, as one might intuit). The cost in extra development time is more then compensated for (by at least an order of magnitude) with savings in reduced defects.

Pair programming was also considered a more enjoyable method of development by the participants in this study. I certainly find it more enjoyable, though I can understand that some software developers don't. If you're a personality who doesn't enjoy constant communication and collaboration then pairing can be tiresome. But, as my friend z once wrote "Soylent Green is people. So is software". Many difficulties associated with the software development process stem from poor communication, and pair programming can go a long way to addressing these problems.