Wednesday, January 23, 2008

Pair Programming Reduces Errors by 80-98%?

Pair Programming is one of the best-known tenets of the eXtreme Programming methodology. It is probably also one of the most controversial. I think it probably has many benefits, but one of the subtler ones revolves not around positive productivity, per se, but rather, mistake avoidance.

Let me tell a non-programming story to illustrate. A few years ago, my wife Beth and a neighbor friend of hers conspired to have us husbands build decks on to hour houses. Neither Dave nor I had ever built anything like a deck before. We were both about the same level of mediocrity as far as home-maintenance DIYers--advanced-beginner to intermediate in terms of skills and competency. But decks sounded good, so we signed on.

It was great to have someone to work with, for many reasons. But the reason I am interested in is short-cuts. Occasionally short-cuts can be good, but probably more often they aren't. Particularly in the hands of novices. Here's what happened, every time I would think of a short-cut (and vice-versa).

Normally, if working alone, I might think of a short-cut, consider it briefly, and then proceed. Often proceeding to regret it, within minutes or hours. However, when working with a partner, the unavoidable first step is to explain the shortcut. And what transpired, much more often than not, was that, about half-way through explaining my short-cut, I would "hear" the bad ideas actually coming out of my mouth, and I would drop the idea abruptly and rather sheepishly.

I think that same principle applies to pair programming. In software, it is the mistakes that kill you. If programmer B were only half as fast as programmer A, but never made a mistake, he would be by far the more productive programmer. So anything that reduces mistakes, really pays off.

To really see how this could work on a pair basis, you need to look at the math, which is simple, but deceptive. Suppose the typical programmer makes mistakes 10% of the time (whatever that means, exactly). If you add a second "pair of eyeballs" to the mix, and assume that their mistakes are non-correlated to those of the first programmer, then you have reduced the mistake rate from 10% to 1%! (10% * 10% = 1%; this is one of many examples of the "power of redundancy")

1 comment:

  1. First time I have heard of this and it makes 100% sense, especially in regards to coding. A second pair of eyes is crucial as everyone's eyses begin to "bug out" after looking at the same code for a while.