Strengthening the case for pair programming

Abstract

design, algorithm, code, or test-does indeed improve software quality and reduce time to market. Additionally, student and professional programmers consistently find pair programming more enjoyable than working alone. Yet most who have not tried and tested pair programming reject the idea as a redundant, wasteful use of programming resources: "Why would I put two people on a job that just one can do? I can't afford to do that!" But we have found, as Larry Constantine wrote, that "Two programmers in tandem is not redundancy; it's a direct route to greater efficiency and better quality." 1 Our supportive evidence comes from professional programmers and from advanced undergraduate students who participated in a structured experiment. The experimental results show that programming pairs develop better code faster with only a minimal increase in prerelease programmer hours. These results apply to all levels of programming skill from novice to expert. Earlier ObservationsIn 1998, Temple University professor John Nosek reported on his study of 15 full-time, experienced programmers working for a maximum of 45 minutes on a challenging problem important to their organization. In their own environments and with their own equipment, five worked individually and 10 worked collaboratively in five pairs. The conditions and materials were the same for both the experimental (team) and control (individual) groups. A twosided t-test showed that the study provided statistically significant results. Combining their time, the pairs spent 60% more minutes on the task. Because they worked in tandem, however, they completed the task 40% faster than the control groups, and produced better algorithms and code. 2 Most of the programmers were initially skeptical of the value of collaborating and

Empirical Findings in Agile Methods

“…The level of experience might even be as low as 10% if the teams practice pair programming [22] and if the makeup of the specific programmers in each pair is fairly dynamic over the project cycle (termed "pair rotation"). Programmers on teams that practice pair rotation have an enhanced environment for mentoring and for learning from each other.…”

Impact of pair programming on thoroughness and fault detection effectiveness of unit test suites

“…Beck and Andres wrote that a pair is even more than twice as effective as the same two people programming solo [2]. However, empirical studies concerning the effort overhead and speedup ratio of the PP practice are inconclusive [29,3,30,31,32,33,5]. According to the empirical results, the effort overhead is probably somewhere between 7%(13% excluding rework) [33] and 84% (obtained in a large one day experiment in 29 international consultancy companies) [5].…”

“…The driver types at the keyboard and focuses on the details of the production code or tests. The navigator observes the work of the driver, reviews the code, proposes test cases, considers the strategic implications [3,4] and looks for tactical and strategic defects or alternatives [5]. In the case of solo programming, both activities are performed by a single programmer.…”

Collaboration in Pair Programming: Driving and Switching

“…Originally, the literature claimed that driver and navigator work on different levels of abstraction; the navigator acts and thinks on a strategic level [2,8] , is responsible for reviewing the driver's work [8,12], and for "watching for defects, thinking of alternatives, looking up resources" [18] whereas the driver is responsible "for typing the code" [8] and for finding "the best way to implement this method right here" [2].…”

“…Over recent years, a wide range of studies [3,13,15,16,18] has investigated PP; most of those studies report positive results indicating benefits of PP. However, some studies are inconclusive and some studies even report contradictory results (see [10]).…”