People have advocated and practiced pair programming for decades, long before it was ever called pair programming. Fred Brooks, author of The Mythical Man-Month [Brooks 1975], has communicated: “Fellow graduate student Bill Wright and I first tried pair programming when I was a grad student (1953–1956). We produced 1,500 lines of defect-free code; it ran correctly first try” [Williams and Kessler 2003].

In the early 1980s, Larry Constantine, author of more than 150 technical articles and 16 books, reported observing “Dynamic Duos” at Whitesmiths, Ltd., producing code faster and more bug-free than ever before [Constantine 1995]. He commented that the code benefited from the thinking of two bright minds and the steady dialog between two trusted programmers. He concluded that two programmers in tandem was not redundancy, but rather it was a direct route to greater efficiency and better quality.

Based upon research findings of the Pasteur project (a large sociological/anthropological study of 50 highly effective software development organizations) at Bell Labs Research, James Coplien published the “Developing in Pairs” Organizational Pattern [Coplien 1995], [Coplien and Harrison 2005] in 1995. Coplien identified the forces of this pattern as “people sometimes feel they can solve a problem only if they have help. Some problems are bigger than any one individual.” The proposed solution of the organizational pattern is to “pair compatible designers to work together; together they can produce more than the sum of the two individually.” The result of applying the pattern is “a more effective implementation process. A pair of people is less likely to be blindsided than an individual developer.”

In 1998, Temple University professor John Nosek was the first to run an empirical study on the efficacy of pair programmers [Nosek 1998]. Nosek reported the results 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, 5 worked individually and 10 worked collaboratively in 5 pairs. The conditions and materials were the same for both the experimental (team) and control (individual) groups. A two-sided t-test showed that the study provided statistically significant results. The pairs spent a total of 60% more total minutes on the task. However, because they worked in tandem, they completed the task 20% faster than the control groups. Nosek also reports that the pairs produced better algorithms and code.

As I mentioned earlier, the emergence of the XP software development methodology in the late 1990s/early 2000s brought the pair programming practice to the forefront. As XP emerged, many people were doubtful about pair programming because they believed that the amount of effort spent on a programming task would double if two programmers worked together.

This incredulousness motivated an extensive empirical study that was run at the University of Utah in 1999 ([Williams et al. 2000], [Williams 2000]), [Williams and Kessler 2000] to isolate and study the costs and benefits of pair programming. Forty-one third- and fourth-year undergraduate students in a software engineering class participated in a structured experiment for the duration of a 15-week semester. On the first day of class, the students were asked whether they preferred to work in pairs or individually, with whom they wanted to work, and with whom they did not want to work. The students were also classified as “High” (top 25%), “Average,” or “Low” (bottom 25%) academic performers based on the grade point average (GPA) in their academic records. Twenty-eight students were assigned to the paired group and thirteen to the solo group. The GPA was used to ensure the groups were academically equivalent. Of the 14 pairs, 13 pairs were mutually chosen, in that each student had asked to work with her partner. The last pair was assigned because the students did not express a partner preference.

All students received instruction in effective pair-programming and were given a paper [Williams and Kessler 2000] on strategies for successful collaboration to help prepare them. Specific measures were taken to ensure that the pairs worked together consistently each week. One class period each week was allotted for the students to work on their projects. Additionally, the students were required to attend two hours of office hours with their partners each week, where they also worked on their projects. During these regular meeting times, the pairs gelled or bonded and were much more likely to establish additional meeting times to complete their work.

The pairs passed significantly more of the automated post-development test cases run by an impartial teaching assistant (see Table 17-1). On average, students who worked in pairs passed 15% more of the instructor’s test cases. This quality difference was statistically significant at p < .01.

The results also indicated that on average the pairs spent 15% more programmer-hours than the individuals to complete their projects. For example, if one individual spent 10 hours on an assignment, each partner in the pair would spend approximately 5 hours and 45 minutes, on average. The median time spent was essentially equal for the two groups, and the average difference was not statistically significant. Even with a 15% increase in programmer time, the improved quality makes pair programming an economically-viable software development practice [Erdogmus and Williams 2003]. The University of Utah study was conducted over a 16-week semester with advanced undergraduates with industry experience. However, these empirical results may be applicable only in an academic setting.

Between the use of the practice in XP and the results of the University of Utah study that indicated the benefits of pair programming without doubling resources, pair programming began to be used more prevalently in industry and education. The next two sections outline the use of pair programming in each of these environments.