When I started pair programming daily, it changed my life and my projects for the better. I often point to pair programming as one of the most influential possible interventions on any projects. Very often, an audience member with a healthy degree skepticism will inquire about the research into pair programming.
Sadly, the practice of software engineering research has not come very far in this area, so the questioner is left unsatisfied. In this blogpost, I will summarize the current state of research into pair programming, and describe my hopes for the future.
Lately, I’ve been talking with researchers at SINTEF about project in-situ studies into different aspects of agile development, including pair programming. As we have several teams that practice pair programming on a daily basis in Steria, I’m hoping that this may finally shine some scientific light on what I believe to be a really good practice.
The current situation is not satisfactory. The body of research into Pair Programming is summarized in the meta-study Are Two Heads Better than One? On the effectiveness of pair programming by DybÃ¥, Arisholm, SjÃ¸berg, Hannay, and Shull in IEEE Software November, 2007.
The meta-analysis looks at twelve papers on pair programming in their assessment of pair programming on three project metrics: Quality, Duration and Effort.
The studies are mostly pointing to the same results: Pair programming seems to improve quality significantly, decrease duration slightly, and increase effort slightly. That is: Pair programming will make your project ship a little earlier, with significantly better quality, but at a higher cost.
Sadly, all the research so far miss some significant factors:
- First: Better quality in the short term may transform into lower cost in the long term. As the studies are all short term, this effect cannot be assessed.
- Second: One of the main reasons we do pair programming is to decrease the effect of absence (vacations, illness, turnover) and suboptimization due to over-specialization. As far as I know, there are no studies that include these effects.
- Third: I’ve found that pair programming is a skill in itself. It takes up to a few months to learn it. All studies of pair programming have been with people who are inexperienced in the practice.
Finally, studies on pair programming seem to conclude that pair programming may be appropriate for juniors or mid-level developers, but that it seldom makes sense for senior developers. I don’t know if I should take that as an insult or not, as I practice pair programming in almost all my programming time. And I would like to consider myself a senior developer. Feel free to disagree.