Richard Stobart has written an excellent article over at ITWales.com that provides some very interesting perspectives on the practice of pair programming.  Conspiracy theorists, cynics, and even customers might view pair programming as an attempt by the global developer community to reduce developer supply and charge higher prices -- after all, two developers can charge more than one. 

Doubling demand on XP projects means more work for developers and reduces the pool available for traditional projects - rates go up and more jobs are secured. Is this the same genius as those 70's marketing execs that added "step 3 - repeat" to double shampoo consumption and therefore sales overnight or are there genuine productivity gains to be had for consultancies and customers?

Richard also prompts us to wonder whether all 'programming pairs' are created equal. He references a study from Tom DeMarco's book 'Peopleware' which shows that the top quartile of developers were 2.6 times more productive than the bottom quartile.

That's a significant saving, more than double the cost of a pair. So, can two bottom quartile developers pairing be as productive as one top quartile developer? Probably not but it's a complex equation with hard-to-quantify variables - in reality the truth of the benefits lie in the sum of the parts.

But Richard argues that pair programming does in fact work, resulting in very real productivity gains and cost savings. Defects caught during development - defects that might not have been caught by a 'lone wolf' programmer - result in far greater cost savings over the long term.  The synergies, and the collective 'flow' gained through pairing can and does result in higher quality code. In fact, Richard's very own company has transformed its development environment to better accomodate and encourage pairing: 

We embrace the productivity gains that we see from pair programming and structure our development environment to accommodate it as much as possible, all our new developers do a paired coding test to ensure that they can fit into this way of thinking. We have pairing stations with 30" monitors, dual keyboards and mice, flat fronted desks and Scrum Masters that encourage pairing.

Richard concludes by advising developers to carefully explain the benefits of pair programming to customers, and to show them that effectively integrating such a strategy into a development environment can result in significant cost savings. 

What are your experiences with pair programming?  Are you currently using it within your organization?  Have the benefits outweighed the 'costs'?