The Pitfalls and Perils of Pair Programming


The concept of pair programming first became popular thanks to “extreme programming” or XP—a set of practices that supposedly allows companies to develop software in a more efficient, more “agile” manner.  Proponents of XP claim that it allows programmers to respond to changing or ambiguous software requirements without sacrificing quality.  Skeptics disagree, arguing that these alleged benefits are either illusory or ,

XP proponents argue that two programming heads are better than one—that two software developers working together will tend to produce better, more reliable and more maintainable than a single programmer working alone.  This practice is known as pair programming, and at first glance, it sounds like a great idea.  Personally though, I think that it smacks of a “one size fits all” mentality.  That is, it assumes that two programmers working in concert will indeed be more efficient and that they will produce better results.  I think there is good reason to believe otherwise.

The much vaunted Williams study

XP fans typically point to an infamous study headed by Prof. Laurie Williams at the University of Utah.  In this study, Williams concluded that pair programming takes 15% more time than solo development, but results in software that is 15% better.  They argue that this modest increase in development time is a small price to pay, since better code quality means that less time and effort will be required later down the road – during testing and maintenance, for example.


I think that there are numerous problems with this study, though.  How did the researchers gauge software quality, for example?  The used the length of code as the quality metric; that is, the shorter the source code, the better they deemed it to be.  The reported, “[The paired teams] consistently implemented the same functionality as the individuals in fewer lines of code.  We believe this is an indication that the pairs had better designs.”  I think this is a hasty leap of logic, to say the least!

Does shorter source code exhibit greater quality?  Sometimes, perhaps.  However, one could just as easily speculate that the longer code contains more bug fixes and safeguards.  In addition, adding more code lines – to implement a design pattern, for example – can make the software more efficient or easier to maintain.  I think that the presumed correlation between code