| layout | title | permalink |
|---|---|---|
default |
Scientific Research Into Pair Programming |
/scientific-research-into-pair-programming |
{% include article-top.html %}
Regrettably, there's not much. But here are the papers worth reading and sharing.
The paper covers much of the existing research (and research-like artifacts, such as surveys).
From their abstract:
Using interviews and controlled experiments, the authors investigated the costs and benefits of pair programming. They 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.
Nosek, J. T. (1998)
A field experiment was conducted using experienced programmers who worked on a challenging problem important to their organization, in their own environments, and with their own equipment. Findings revealed that all the teams outperformed the individual programmers, enjoyed the problem-solving process more, and had greater confidence in their solutions.
Teams completed their task 40% faster than the individuals (and this result was statistically significant).
Studies in industry are rare, so this one is a nice find.
Jensen, R. W. (1996)
(No link available. Summary taken from Pair Programming Illuminated, p. 35)
Regarding the performance of pairs vs individuals:
Final project results were outstanding. Total productivity was 175 lines per person-month (lppm) compared to a documented average individual productivity of only 77 llpm.
The error rate […] was three orders of magnitude lower than the organization's norm.
(Pairs had a defect rate one thousandth of individuals'. Holy crap!)
Wiliams, L. A. (2000)
An experiment was run in 1999 with approximately 40 senior Computer Science students at the University of Utah. Two-thirds of the students worked in two-person collaborative teams […]. The other students worked independently […] to develop the same assignments. The productivity, cycle time, and quality of the two groups have been compared. Empirical results point in favor of the collaborative teams […].
One key finding: the pairs took 15% more developer hours to produce their solutions, but those solutions had 15% fewer bugs.
Williams, Kessler, Cunningham, Jeffries
An easy read paper that summarizes some of the research above, as well as providing supporting anecdotes from industry veterans.
The authors also summarize the results of the paper just above, The Collaborative Software Process:
The pairs always passed more of the automated post-development test cases. Their results were also more consistent, while the individuals varied more about the mean. Some individuals didn’t hand in a program or handed it in late; pairs handed in their assignments on time. We attribute the pairs’ punctuality to positive pressure the partners exert on each other. They admit to working “harder and smarter” because they don’t want to let their partner down.
Do you know of any research into pair programming (with positive *or* negative results) that should appear here? Please open an issue.
{% include navigation-buttons.html previous-title="How To Pair With A Junior Dev" previous-url="/pair-programming-guide/how-to-pair-with-a-junior-developer" next-title="Great External Resources" next-url="/pair-programming-guide/links" %}