"Why in the world would we use two people to do the job of one?" This is often the initial reaction to people when first introduced to the idea of pair programming. In essence, they perceive pair programming as doubling the cost of writing any segment of code. Dave Nicollete offers some quantitive ideas to help show how pair programming can save money, not waste it.
The economic value proposition of pair programming is most often misunderstood as a result of a misperception that programming is mostly about typing. In reality, of course, the majority of programming is really about thinking, and as a result provides endless opportunities to make bad decisions and create errors - errors that will ultimately cost developers (and thus the organization) time in the future.
This is where the economic value proposition of pair programming is founded, and also why it is hard to quantify. As Dave Nicolette summarizes in a recent article:
The value of pairing comes in the form of very small course corrections that prevent errors from occurring in the first place. The course corrections are of such small scope and they occur so seamlessly within the pair's work flow that they are usually not noticed at all...The value is easy to overlook because the effect of pairing is to prevent situations that would have caused extra work at some future time...It's not easy to observe or quantify these effects after the fact, because the bad stuff never happens.
So, the value of pairing comes in the form of saved future time, and, afterall, "time is money". But, how much money? In this same article, Dave took a stab at presenting some ideas to answering this question.
During a recent pairing session, Dave kept track of how often one pair helped the other by catching a mistake as well the design-related discussions that occurred. Afterwards, they decided how much future time each of these things saved, then with this information went on to do some more calculations:
In one of his early books, Alistair Cockburn computed that the cost of an IT professional amounts to about $2.10 per minute...In our pairing session we had two mini design discussions that led to small refactorings. By our reckoning, that saved four hours of future code maintenance effort. That's worth about 2.1 x 120 = $252.00. There were 12 moments when one of us noticed a minor mistake. If those occurrences saved an average of 30 seconds debugging effort, then it was worth .5 x 2.1 x 12 = $12.60. In total, we saved the company $274.60 in 90 minutes' time, or an hourly saving rate of about $180.00.
...
The company has a small IT department with a total of about 40 developers working in several XP teams. If we assume the developers pair about 5 hours a day, then that's 20 pairs x 5 hours x 5 days per week = 500 pairing hours per week. Assuming a savings of $180 per hour per pair, that makes the average hard savings attributable to pairing $90,000 per week. If that rate of work is more-or-less constant throughout the year, and the teams work 50 weeks a year (it's in the United States, so vacation time is short), the company enjoys a savings of about $4.5 million per year specifically because its software development teams pair-program as a standard practice.
$4.5 million for this organization of only 40 developers. As Dave concedes, these are only rough calculations derived from only a single pairing session, so this is by no means scientific, but it does nonetheless demand consideration.
What do you think?
