Wednesday, April 14, 2021 RegisterLogin
 Cool links
You must be logged in and have permission to create or edit a blog.
 Ái Việt's Blog
Mar 22

Written by: AIViet Admin
3/22/2009 6:57 PM

Pair-Programming: Is Two Necessary “Better” than One?

1.     Introduction

Pair-programming (PP) is a practice in which two people working side-by-side program together using shared computer resources [5]. The practice was prescribed as one of the core techniques in eXtreme Programming (aka XP) software methodology. In any project, one of the key factors in ensuring its success is that project team members collaborate with each others in pursuit of team’s goals. In XP, collaboration between team members has been formalized to the extreme: “All production code is pair programmed” [5].  In other words, pair-programming, from being an activity that happens among developers from time to time by necessity, XP has made it into an all day long human-human interaction activity on a daily basis. XP version of pair-programming introduced a new concept of role-based protocol:

  • Driver: Code typer focuses on the “tactical” details of implementation.
  • Navigator: Reviewing code as entered by driver and acting as “strategy” thinker on the common task at hand.

Roles are expected to switch between pair-partners on regular basis. Such “extreme” practice of pair-programming in XP has opened up many interesting issues that could be summed up in a philosophical question: Is Two necessary “better” than One?


Since the formalization of pair-programming by XP movement about a decade ago by Kent Beck [11], there has been researches in many aspects of such practice. Many of these studies have been conducted with classroom settings [2, 3, 4, 6, 9]. Findings from these studies strongly supported some of the claimed benefits of pair-programming: better code quality, higher productivity, increasing job satisfactions, etc [4]. Nevertheless, from similar experiments in industrial settings with professional programmers, the results were going from less positive [1] to contradictory [10]. In the following section, the paper will review findings in literature in an attempt of understanding what kind of benefits pair-programming would bring about; under what circumstance the benefits would emerge; and how significant the benefits would be as compared to solo-programming.


2.     Literature Review

In an attempt of quantifying the cost and benefits of pair-programming over solo-programming in a project, Frank and Matthias (2003) [8] has devised a set of metrics. In specific, two of these metrics were specially designed to measure pair-programming’s advantage over solo developer:

Based on previous studies from other researchers, the pair speed advantage and pair defect advantage were believed to give about 33% and 15% respectively improvement over solo-programming [8]. Combining pair-programming specific metrics with others: product metrics (e.g., product size and modules interdependency) and project context metrics (e.g., market pressure, team size, salary, etc.), the authors came up with a mathematical model that based on concept of Net Present Value (NPV):

Parameters in the NPV model in turn were highly sensitive to PSA and PDA. As warned by the authors, a single NPV value in dollar should be used with caution; while considering a good indicator in justifying the cost/benefit of pair-programming to a project, the model itself has made key assumptions that might not hold true to all projects. For example: pair-programming’s advantages (PSA and PDA) were assumed constants factors that were independent of team size, team complexity, and so on.

In a later attempt, Frank and Matthias (2004) [7] extended the NPV model for pair-programming by taking account of the fact that PSA and PDA in practice were complex variables of many factors: learning curve during project warm-up phase, times to get newcomers come to speed, number of pairs, and so on.

Figure 1: PSA as a function of times (days). Source [7]. This model would capture the reality better as compared to the former one that assumed PSA a constant factor.


Even with the extended - closer-to-reality - NPV model, authors made an important remark that while human factors were expected to play an important role in the success of pair-programming, they had not been accounted for in the model. In specific, the authors speculated pair-programming’s effectiveness would be adversely affected, should programmer resist the practice.

Brian (2006) [2], in a survey with pair-programming students as below:

  • Q1 “I like pair programming”
  • Q2 “I would like to pair program again in another class or in my job”
  • Q3 “I learned more in this class because I pair programmed”
  • Q4 “I had more fun in this class because I pair programmed”

Using Likert scale to rate survey responses, the author noted an interesting finding that pair-programming would more likely to benefit those who were willing to participate in the practice. Implication of such finding suggested that human-human interactions could be a decisive factor in the success pair-programming.


The educational benefits brought about by pair-programming were well evidenced in a recent study by Grant et al. (2008) [9]: Students who pair-programmed scored about 10% better in individual tests and as a result they were about three times more likely to complete the course successfully. This result was in agreement with past study’s by Emilia et al. (2006) [6].

Table 1: Comparing passing rate between paired and solo students. Source [6].

Chi-square test on experiment’s data rejected the null hypothesis. It validated the hypothesis that pair-programming improved the student learning experience and hence resulted in a higher passing rate. It was noticed that pair-programming students from Asian ethnic group performed consistently well in exam, assignment, and test. The study also suggested a correlation between students’ attitude toward pair-programming and pair partners’ communication effectiveness.

To ensure pair-programming’s benefits for educational purpose, David Preston (2006) [4] made a number of recommendations to instructors:

  • Designing common task to stimulate higher-level reasoning strategies, critical thinking, problem solving, and creativity.
  • Small group learning between two to six pairs.
  • Coaching students on cooperative behavior by showing positive and negative examples.
  • Encouraging pair-programming students to rotate between roles frequently: driver and navigator.
  • Putting greater weight on individual test score to emphasize individual learning achievements.


Allen et al. (2004) [1] reported an intriguing finding that in contrary to many other existing studies, based on the experiment with a team of 48 professional developers with an average of 10 years of experience, pair-programming did not deliver the supposed benefits. Results of the study were as follows:

Table 2: Productivity versus concurrency level (pair-programming activity level). Source [1]. Productivity was at lost when two developers concurrently working together.

The t-test results indicated that the significant loss of productivity due to high level of pair-programming activity did not happen by chance. It is important to point out that the practice of pair-programming in the experiment did not follow the prescribed driver-navigator roles defined by XP. In explaining such contrast results to existing studies, the authors pointed to the fact that compared to classroom settings, there have been far fewer number of studies on pair-programming conducted under industrial settings. And there were significant differences between the two environments. For one, it would be unlikely to have student-student pairs working together more than 1-hour/day on a day to day basis. On the other hand, in the case of professional developers practicing XP, this kind of workday would not be uncommon. While acknowledging there existed pair-programming’s other benefits rather than productivity, the authors called for more industrial-based studies on role-based pair-programming.


Jan Chong and Tom Hurbutt (2007) [11] challenged the conventional wisdom of pair-programming driver -navigator roles. In their long term study with two teams of professional developers, what had been observed did not match the roles defined by XP. In place of the widely belief of pair-programming driver-navigator roles, the study found that knowledge parity of the pair dictated the nature of interaction between pair-partners: In the presence of an expert partner, the less knowledgeable programmer tended to fade away into passive mode; leaving the expert one alone with the common task. Based on such observations, the authors went on to argue that confining developers into the rigidly defined roles of driver-navigators impacted the effectiveness of pair-programming. Instead several recommendations were made to ensure pair-programming’s effectiveness:

  • Both pair-partners should take on the driver and navigator responsibilities at the same time. Having input devices accessible to both pair-partners. That should help both partners to stay focus and engaged.
  • Leveling knowledge parity as much as possible when forming pair. Especially in a time pressure, forming novice-expert pair would be highly undesirable.
  • Pair rotation should be done at minimal disruption to ongoing task. It would be undesirable to have rotated programmer have to get to speed with the common task.

In conclusion, while appreciating valuable observations from classroom settings experiments, the authors echoed the concern from similar industrial-based studies that professional environment was different; it would be hard press to generalize findings between two environments completely.


The last study to be reviewed was from Hanna Hulkko, Pekka Abrahamsson (2005) [10]. This perhaps was the most comprehensive study on the impact of pair-programming on real software projects. There were four case projects in the study:

Table 3: Summary of the four case projects in the current study. Source [10].


Literature review by Hanna et al. [10] resulted in a summary below: 

Table 4: Summary of main findings of other existing studies. Source [10]. RQ = Research Question.


Table 5: Summary of the empirical results in the current study. Source [10].

3.     Conclusions

It is an appealing proposition in claiming that two programmers pairing together on the same tasks would result in higher quality of deliverable without impacting on time to delivery. Findings from experiments on pair-programming within classroom environment were more supportive of the claim than those from industrial-based studies. Gaps in results obtained from classroom vs. industrial settings are yet to be analyzed. The fact was that empirical evidence regarding pair-programming’s effectiveness from industry was scarce. The currently available empirical evidence has not been able to confirm such a claim in industrial environment in a decisive way. Nevertheless researchers generally agreed that given the right conditions, pair-programming would bring some benefits. Pair-programming’s benefits were quantifiable somewhat in classroom settings. As for industrial settings, how significant these benefits would be are yet to be measured with some confidence. Most (if not all) of the experiments on pair-programming have been conducted in western culture environment. It would be interesting to replicate pair-programming experiments in the context of other cultures such as Asians where certain values are alien to the West, for example, Indian teams would observe a stricter hierarchy of seniority; or Japanese team members tend to be diplomatic towards their colleagues.

4.     References

[1]   Allen Parrish, Randy Smith, David Hale, and Joanne Hale, “A Field Study of Developer Pairs: Productivity Impacts and Implications”, IEEE Software, 2004.

[2]   Brian Hanks, “Student Attitudes toward Pair Programming”, ITiCSE’06, June 26–28, 2006, Bologna, Italy.

[3]   Brian Hanks, “Student Performance in CS1 with Distributed Pair Programming”, ITiCSE’05, June 27–29, 2005, Monte de Caparica, Portugal.

[4]   David Preston, “Using Collaborative Learning Research to Enhance Pair Programming Pedagogy”, ACM SIGITE Newsletter, Vol. 3, No. 1, January 2006 16.

[5]   Extreme Programming Org, “The Rules and Practices of Extreme Programming”,, 2008.

[6]   Emilia Mendes, Lubna Al-Fakhri, Andrew Luxton-Reilly, “A Replicated Experiment of Pair-Programming in a 2nd-year Software Development and Design Computer Science Course”, ITiCSE'06, June 26–28, 2006, Bologna, Italy.

[7]   Frank Padberg, Matthias M. M¨uller, “Modeling the Impact of a Learning Phase on the Business Value of a Pair Programming Project”, Proceedings of the 11th Asia-Pacific Software Engineering Conference (APSEC’04).

[8]   Frank Padberg, Matthias M. M¨uller, “Analyzing the Cost and Benefit of Pair Programming”, Proceedings of the Ninth International Software Metrics Symposium (METRICS’03).

[9]   Grant Braught, L. Marlin Eby, Tim Wahls, “The Effects of Pair-Programming on Individual Programming Skill”, SIGCSE’08, March 12–15, 2008, Portland, Oregon, USA.

[10]Hanna Hulkko, Pekka Abrahamsson, “A Multiple Case Study on the Impact of Pair Programming on Product Quality”, ICSE’05, May 15–21, 2005, St. Louis, Missouri, USA.

[11]Jan Chong, Tom Hurlbutt, “The Social Dynamics of Pair Programming”, 29th International Conference on Software Engineering (ICSE'07)


Copyright ©2009 AIViet Admin

Copyright 2008 by AIViet Terms Of UsePrivacy Statement
Downloaded from