Pair Programming

This pair programming study was being passed around at work, which always sends a chill down my spine.

In case you are not familiar with this confronting practice,

The official definition of pair programming is two programmers working together, side by side, at one computer collaborating on the same analysis, design, implementation, and test. In other words, consider it like two programmers using one pencil.

Its main thrust of the paper is that working as a pair each programmer achieved 227% of the average level of output in the organisation. Fascinating stuff, but not without its difficulties. I am not convinced that lines of code is a meaningful way to measure programmer productivity. I suspect that the average programmer might easily double their output by this measure just by being told that the lines of code they commit is being tallied.

By this measure I should have been paying to come to work this month. My main task has been refactoring about 6000 lines of code into about 2000 lines of code. I appear to have been doing negative amounts of work.

But that is all a side note, I was much more fascinated by the effect of pair programming on error rates. The summary data is helpfully provided as an image of a table. Errors decreased by three orders of magnitude.

Which sounds great, but think for a minute what that means. The author chooses not to disclose the normal error rate for solo programmers in the organisation, except to say that it was in line with the industry at the time. One data point given though is that a 10000 line task delivered by pairs had only two coding errors and one design error. That sounds pretty good to me … but if the pairs were producing 0.001 times the errors of solo programmers as the study claims, then solo programmers would have been expected to deliver 2000 coding errors and 1000 design errors in the same 10000 line task.

One coding error per five lines of code, and one design error per ten lines of code seems highly improbable to me, unless each pair consisted of one programmer doing 80% of the work and one rhesus monkey who without supervision would have just bashed keys randomly. Today of course, people would probably assume the output produced by the monkey was a valid Perl program, but as Perl had not been invented when the experiment was conducted I guess they spotted them as errors.

I remain unconvinced, and cannot think of pair programming without thinking of the PairOn chair … with apologies to Cenqua who I stole the image from and HermanMiller who they stole the dot com bubble icon the Aeron from.


Leave a Reply