Topic: Value proposition
I'm coaching a team that is relatively new to techniques like TDD and pairing. A team member asked me to pair with her the other day to have a look at her unit test cases. Like many people who are still getting used to building up a suite of automated tests, she had been writing Happy Path tests and only an occasional abnormal case. She felt that she wasn't considering enough test cases, but she wasn't sure what to add. In the course of the pairing session, we started building a new feature in the application and wrote test cases for boundary conditions, null arguments, exceptions, resource unavailable situations, and so forth.
The TDD coaching as such was pretty typical, but the interesting thing was that she asked why people should pair unless they're transferring knowledge or mentoring one another. I took the opportunity to demonstrate one aspect of the value proposition of pairing. As we worked, whenever one of us helped the other by noticing a minor mistake — mis-keyed keyword, missing closing tag, forgotten semicolon, etc. — I made a tick-mark on a piece of paper. Furthermore, whenever we had a brief design discussion as we were working — pull this method up? break up this if/else block? etc. — I tracked it with a second set of tick-marks.
After our last check-in for the session, we took a few minutes for a mini-retrospective. I asked her to make a reasonable guess about the amount of time we had saved each time one of us noticed a minor coding error in the moment. She figured each one was worth about 30 seconds, based on the notion that finding the error after the fact while debugging would have taken about that long on average. We also talked about the brief design discussions that had taken place. We figured that on average each of the resulting design improvements prevented two hours of future code maintenance effort by avoiding a little bit of technical debt.
In one of his early books, Alistair Cockburn computed that the cost of an IT professional amounts to about $2.10 per minute. That's a little higher than my own scratch calculation, but he's a Doctor so I'll go with his numbers. 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.
Bear in mind these numbers are just rough-and-ready estimates based on our observations of a single pairing session. They may be high or low. The calculation also ignores the opportunity cost we avoided by keeping the code base clean. What I mean by "opportunity cost" in this context is the cost of the time developers could not have spent on value-add work in future modifications, if they had to spend the time working around the technical debt that we avoided. (That's a clumsy way to say it; I hope it's clear enough.)
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.
Of course, by projecting the results of one pairing session in this way we are subject to the effect of cumulative error. If you think the numbers are inflated, then go ahead and chop them in half and say that the company is saving a mere $2.25 million per year. The precise number isn't really the point; the point is that pairing really does deliver hard value. Given that a professional's time is the most expensive component of IT cost, techniques that save professionals' time are well worthwhile.
The team member found the numbers quite surprising. I think her reaction is normal. We humans tend to look for dramatic, memorable events as evidence that something yields value. Pairing rarely generates dramatic, memorable events. 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.
This is as it should be; clean code should be a natural outcome of our work, and not something that calls attention to itself by virtue of being abnormal. 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. Defects do not enter the code base. Technical debt does not accumulate. It's not easy to observe or quantify these effects after the fact, because the bad stuff never happens.
