Pair Programming happens to be one of the first casualties when shops hastily jump into agile bandwagon. (TDD/Test Driven Development is another). Maybe because it’s counterintuitive to many. The whole effectiveness of pair programming gets questioned (How can two working together not be wasting time?). Even Dilbert had his say.
Now with agile way of development gaining more ground, in all flavours – offshored, distributed, CMMised, PMIed, whatever – resistance to any practice can only weaken the whole concept of agile and squeezing the last drop out of it. (Though pair programming is not strictly tied to agile method and one can happily do it in non-agile settings, it gained more mileage piggybacking agile)
One way to counter counterintuitiveness is with empirical studies. Or with studies which explains why it works.
Stuart Ray has come up with such a brilliant article on pair programming which dives into cognitive science to explain how pair programming works. The article delves beautifully in the workings of brain and human behavior, and perhaps corroborates the fact that brain is more a social organ and cannot but feel better with increased chance of social interaction. He goes on to advance four mechanisms of pairing.
One is “Pair programming chat“. It seems talking about programming problems, even to oneself, helps getting unstuck. Stuart Ray goes on to give a wonderful cognitive rationale behind it with language module doing the trick with integrating knowledge held in other modules.
Carruthers suggested that we must rely on the language module posing the right question and that the other modules don’t usually present information spontaneously. However, when we hear the right question, our brains make the necessary information available, and the language module can then perform rudimentary inference and draw the obvious conclusions. Carruthers suggested that the key is posing a question that’s “both relevant and fruitful.” The right question draws forth the crucial knowledge, and in a moment of epiphany, the answer becomes obvious.
Next being “Pair programmers notice more details“. In this Stuart Ray talks how more details gets noticed under pair programming. So, two people programming together won’t have the same prior knowledge or categorization: one will presumably spot some things faster and the other different things. That is till pair fatigue sets in.
Then comes “Fighting poor practices“. Pair programming can nudge programmers to follow best practices or rather, to avoid poor practices. In his words, Pair programmers might be less susceptible to poor practices because they can promise to write code in a particular way and ensure that each other’s promises are kept.
And finally, “Sharing and judging expertise”. Programming is one area where you never know how skilled one is unless you get to work together with her. Stuart Ray argues rightly that the individual skill levels become transparent in a team which does peer programming. This argument might also help in managing or rewarding performance of people at individual level.
I tried to find some empirical studies on effectiveness of pair programming. In one study in Norway, 295 programmers were used to do a controlled experiment on pair programming. The results of this experiment do not support the hypotheses that pair programming in general reduces the time required to solve the tasks correctly or increases the proportion of correct solutions. On the other hand, there is 84% increase in effort to perform the tasks correctly. However, on the more complex system, the pair programmers had a 48 percent increase in the proportion of correct solutions but no significant differences in the time taken to solve the tasks correctly. I believe the experiment missed out on a significant factor of pair programming effectiveness increasing with gelled teams and shared context, which is expected in real projects.
In one study to analyze cost and benefit for pair programming, Alistair Cockburn and Laurie Williams, found that for a development-time cost of about 15%, pair programming improves design quality, reduces defects, reduces staffing risk, enhances technical skills, improves team communications and is considered more enjoyable at statistically significant levels. To justify economics, the authors stresses the point that pair/collaborative programming reduces defects by a huge margin even if there is small increase in development effort, which in the end compares favorably cost-wise towards pair programming.
It will only help to consider such studies (or better trying it out) before ditching pair programming just because it happened to be counterintuitive to conventional wisdom. It will be a shame if in a rush to get agile branded shops cherry pick agile practices instead on building a foundation of right culture. It might help in sales gimmicks but not in greater good of agile.