focusprocess diversity

Strengthening the Case for Pair Programming

The Laurie Williams, North Carolina State University industry has Robert R. Kessler, University of Utah practiced pair programming—two Ward Cunningham, Cunningham & Cunningham programmers Ron Jeffries working side by side at one or years, programmers in industry have claimed that by working computer on the collaboratively, they have produced higher-quality software prod- same problem— ucts in shorter amounts of time. But their evidence was anecdotal with great success and subjective: “It works” or “It feels right.” To validate these for years. But F people who haven’t claims, we have gathered quantitative evidence showing that pair program- tried it often reject ming—two programmers working side by side at one computer on the same the idea as a waste of resources. The authors design, algorithm, code, or test—does in- programming skill from novice to expert. deed improve and reduce demonstrate that time to market. Additionally, student and Earlier Observations using pair professional programmers consistently find In 1998, Temple University professor programming in pair programming more enjoyable than John Nosek reported on his study of 15 the software working alone. full-time, experienced programmers work- development Yet most who have not tried and tested ing for a maximum of 45 minutes on a chal- process yields pair programming reject the idea as a re- lenging problem important to their organi- dundant, wasteful use of programming re- zation. In their own environments and with better products in sources: “Why would I put two people on a their own equipment, five worked individu- less time—and job that just one can do? I can’t afford to do ally and 10 worked collaboratively in five happier, that!” But we have found, as Larry Con- pairs. The conditions and materials were more confident stantine wrote, that “Two programmers in the same for both the experimental (team) programmers. tandem is not redundancy; it’s a direct route and control (individual) groups. A two- to greater efficiency and better quality.”1 sided t-test showed that the study provided Our supportive evidence comes from statistically significant results. Combining professional programmers and from ad- their time, the pairs spent 60% more min- vanced undergraduate students who partic- utes on the task. Because they worked in ipated in a structured experiment. The ex- tandem, however, they completed the task perimental results show that programming 40% faster than the control groups, and pairs develop better code faster with only a produced better algorithms and code.2 minimal increase in prerelease programmer Most of the programmers were initially hours. These results apply to all levels of skeptical of the value of collaborating and

0740-7459/00/$10.00 © 2000 IEEE July/August 2000 IEEE SOFTWARE 19 You know what I like about pair programming? First, it’s something that has been shown to help produce quality products. But, it’s also something that you can easily add to your pro- cess that people actually want to do. It’s a conceptually small thing to add, as opposed to having an overblown methodology shoved down your throat. And, when times get tough, you wouldn’t likely forget to do pair programming or decide to drop it “just to get done.” I just think the idea of working together is a winner.

—Chuck Allison, Consulting Editor, C/C++ Users Journal (in a conversation with Laurie Williams)

thought it would not be an enjoyable at all times and wholly share the ownership process. But, according to Nosek, “To the of the work product, whether it is a morn- surprise of the managers and participants, ing’s effort or an entire project. all the teams outperformed the individual Ideally, pair programmers will always programmers, enjoyed the problem-solving work together. But reality—illness, time process more, and had greater confidence in conflicts, or even efficiency—dictates that at their solutions.”2 times the pair must split. Experienced pair Pair programming is not new. In 1995, programmers prioritize the parts of the de- Larry Constantine reported observing pairs of velopment cycle, deciding which are most programmers producing code faster and freer important to work on together and which of bugs than ever before.2 The same year, Jim can be done separately. They must also de- Coplien published what he called the devel- cide what to do with the independently de- oping-in-pairs organizational pattern.3 veloped work when they reunite. When a In 1996, code developer and larger group adopts pair programming as consultant , with authors Ward the normal way of working, the long-term Cunningham and Ron Jeffries, began devel- continuity of a particular pair becomes less oping the software important. By pairing regularly with all development methodology (see the sidebar). members of the group, an individual pro- XP is now practiced by programmers grammer maintains sufficient general aware- worldwide. A significant part of XP is pair ness to substitute for a missing partner at a programming, and people who practice XP moment’s notice. are the largest known group of pair pro- Unanimously, the pair programmers we grammers. The XP methodology’s success have observed agree that pair analysis and rate is so impressive that it has aroused the pair design are critical to success. That is, curiosity of many re- two brains are better than one when per- searchers and consultants. The XP founders forming analysis and design. Pairs consider credit much of this success to the use of pair many more possible solutions to a problem programming by all XP programmers, ex- and converge more quickly on which solu- perts and novices alike. tion to implement. According to researchers Nick Flor and Edwin Hutchins, the feed- The Development Cycle back, debate, and idea exchange between In pair programming, two programmers partners significantly decrease the probabil- jointly produce one artifact (design, algo- ity of proceeding with a bad design.4 Col- rithm, code). The two programmers are like laborators often can perform tasks that are a unified, intelligent organism working with too challenging for one to do alone. In an one mind, responsible for every aspect of anonymous online survey (http://limes.cs. this artifact. One partner, the driver, con- utah.edu/questionnaire/questionnaire.htm), trols the pencil, mouse, or keyboard and one professional programmer reflected, “It writes the code. The other partner continu- is a powerful technique as there are two ously and actively observes the driver’s brains concentrating on the same problem work, watching for defects, thinking of al- all the time. It forces one to concentrate ternatives, looking up resources, and con- fully on the problem at hand.” sidering strategic implications. The partners While one partner is busy typing or writ- deliberately switch roles periodically. Both ing down the design, the other partner can are equal, active participants in the process continuously review the design and think

20 IEEE SOFTWARE July/August 2000 What Is eXtreme Programming? the discipline of writing tests first and the complementary, eXtreme Programming is a software development method though quite distinct, discipline of writing simple solutions. that favors informal and immediate communication over the de- Developers expect their intentions to show clearly in the tailed and specific work products required by many traditional code they write and refactor their code and other’s if neces- design methods. Pair programming fits well within XP for rea- sary to achieve this result. A partner who has been tracking sons ranging from quality and productivity to vocabulary devel- the programmer’s intention is well equipped to judge the opment and cross training. XP relies on pair programming so program’s expressiveness. heavily that it insists all production code be written by pairs. Developers continuously integrate their work into a single XP consists of a dozen practices appropriate for small to development thread, testing its health by running compre- midsize teams developing software with vague or changing re- hensive unit tests. With each integration, the pair releases quirements. The methodology copes with change by delivering ownership of their work to the whole team. At this point, dif- software early and often and by absorbing feedback into the ferent pairings can form if another combination of talent is development culture and ultimately into the code. more appropriate for the next piece of work. Several XP practices involve pair programming: 1 Developers work on only one requirement at a time, usually To learn more, see Kent Beck’s book, or consult the eXtreme the one with the greatest business value as established by Programming Roadmap at xp.c2.com, where a lively commu- the customer. Pairs form to interpret requirements or to place nity debates each XP practice. their implementation within the code base. Developers create unit tests for the code’s expected behavior Reference and then write the simplest, most straightforward implemen- 1. K. Beck, eXtreme Programming Explained: Embrace Change, tations that pass their tests. Pairs help each other maintain Addison Wesley Longman, Reading, Mass., 2000.

more strategically about its implications. Programmers view pair analysis and de- Will it run into a dead end? Is there is a bet- sign as more critical than pair implementa- ter strategy? Thus, pair programming pre- tion. Pairs report that they sometimes work vents design defects or removes them almost on implementation individually, usually the as soon as they hit the paper. A further ben- rote, routine, or simple coding phases of a efit is the elimination of design tunnel vi- project. They find that doing this type of pro- sion—making a design decision and sticking gramming individually is more effective. De- with it no matter what. With partners re- velopers report that having a partner for de- viewing and questioning decisions, the ex- tail-oriented tasks such as drawing a graphi- ploration of design alternatives increases. To cal user interface doesn’t help much. Some prepare for an effective joint analysis and de- programmers code average-complexity mod- sign session, programmers should individu- ules individually if a situation such as a time ally research the problem they need to solve conflict dictates, but most immediately feel and perhaps do experimental prototyping. uncomfortable and more error prone. Some After developing a quality design, the even say that any work done individually pair must implement it. Again, one pro- should be scrapped and redone by the pair. grammer is the driver, who types code into Most programmers perform a thorough re- the computer, while the other observes, con- view of the individual work before incorpo- tinuously reviews the code, and considers rating it in the project. A small minority inte- the implementation’s strategic implications. grate individual work without review. This side-by-side form of code review is an The least critical part of the development effective and efficient form of defect re- cycle is pair testing, as long as the pair de- moval. As Gerald Weinberg observes, velops the test cases together. Pairs some- times split up to run test cases, often side by “The human eye has an almost infinite side at two computers. When they discover capacity for not seeing what it does not defects, the partners usually rejoin to find want to see.... Programmers, if left to the best solution. their own devices, will ignore the most glaring errors in their output—errors University Experiment that anyone else can see in an instant.”5 In 1999 at the University of Utah, senior software engineering students participated With pair programming, four eyeballs in a structured experiment. Its purpose was are better than two, and a huge number of to validate quantitatively the anecdotal and defects are prevented right from the start. qualitative pair-programming results ob-

July/August 2000 IEEE SOFTWARE 21 served in industry. All students attended the als. In the university experiment, the stu- same classes, received the same instruction, dents generally adjusted after the first as- Some and participated in class discussions on the signment, although some reported an even pros and cons of pair programming. On the shorter adjustment period. organizations first day of class, 35 of the 41 students For the first assignment, the pairs finished that use pair (85%) indicated a preference for pair pro- in a shorter elapsed time and produced a bet- programming gramming. Later, many of the 35 admitted ter product than the individuals. On aver- that they were initially reluctant, but curi- age, however, they took 60% more pro- heavily have ous, about pair programming. grammer hours to complete the assignment. achieved We divided the students into two groups, These results are similar to Nosek’s results both composed of the same mix of high, av- described earlier. After the adjustment pe- superior erage, and low performers, as determined by riod, this 60% decreased dramatically to a results. their grade point averages. Thirteen students minimum of 15%. The end of the second as- formed the control group, in which all signment marked an important milestone: worked individually on all assignments. all students reported they had overcome the Twenty-eight students formed the experimen- constant urge to grab the mouse or keyboard tal group, in which all worked in two-person, from their partner’s hands. collaborative teams on the same assignments It doesn’t take many clean compiles or as the individuals. The collaborative pairs declarations of “We just got through our also had additional assignments to keep the test with no defects!” for the partners to feel workload equal between the two groups. as one. Tom DeMarco and Timothy Lister All 28 students in the experimental group describe this type of union as had expressed an interest in pair program- a jelled team.... a group of people so ming. Some students in the control group strongly knit that the whole is greater had wanted to try pair programming. Prior than the sum of the parts. The production to enrolling in this class, the students had of such a team is greater than that of the significant coding practice. Most had indus- same people working in unjelled form. try internship experience, and most had Just as important, the enjoyment that peo- written small compilers, operating system ple derive from their work is greater than kernels, and interpreters in other classes. what you’d expect given the nature of the The experiment compared cycle time, pro- work itself. In some cases, jelled teams ductivity, and quality between the two groups. working on assignments that others would The students recorded the time they spent on declare downright dull have a simply mar- the project in a Web-based tool. An impartial velous time.... Once a team begins to jell, teaching assistant executed automated testing the probability of success goes up dramat- to analyze programming quality. ically. The team can become almost un- 7 Pair Jelling stoppable, a juggernaut for success. Long conditioned to working alone, Jon Katzenbach and Douglas Smith ex- many programmers venture into their first plain what happens when a team jells: The pair-programming experience skeptical of members of such a team learn the strengths benefiting from collaborative work. They and weaknesses of each member.8 With this wonder how much additional communica- knowledge, they can adjust their activities tion will be required; how they will adjust to exploit strengths and avoid weaknesses. to the other’s work habits, programming As a result, the team’s productivity exceeds style, and ego; and whether they will dis- the sum of its individuals’ productivity. agree on aspects of the implementation. In- deed, programmers go through an initial ad- Pair-Programming Results justment period in the transition from soli- Some may question the value [of pair pro- tary to collaborative programming. (A gramming] if the collaborators do not recent article provides guidelines on making perform “twice” as well as individuals, at this transition.6) Our anecdotal evidence least in the amount of time spent. For in- and observations show that in industry this stance, if the collaborators did not per- adjustment period varies from a few hours form the task in half the time it takes an to several days, depending on the individu- individual, it would still be more expen-

22 IEEE SOFTWARE July/August 2000 Table 1 Percentage of Test Cases Passed* Individuals Pairs sive to employ two programmers. How- Program 1 73.4 86.4 ever, there are at least two scenarios Program 2 78.1 88.6 where some improved performance over Program 3 70.4 87.1 what is expected or possible by a single Program 4 78.1 94.4 programmer may be the goal: (1) speed- ing up development and (2) improving *The difference in quality levels is statistically significant to p < 0.01; p is the probability that these results could occur by chance. software quality.2

Some organizations that use pair pro- benefits found in our study, we can think of gramming heavily have achieved superior re- three reasons why pair programming might sults. The largest example is the Chrysler be more valuable to industry than our re- Comprehensive Compensation System (the sults indicate. First, the longer defects re- C3 project discussed in Ron Jeffries’ side- main in the product, the more costly it is to bar). After finding significant initial develop- find and fix them. The rework necessary to ment problems, Beck and Jeffries restarted bring individual programmers’ quality lev- the development using XP principles, includ- els up to that of collaborative programmers ing the use of pair programming. In the last could be very time consuming and expen- five months of development, almost the only sive. Some of these defects could escape to defects that made it through unit and func- the customer. Second, unclear designs are tional testing were written by solo program- difficult to change in later releases, resulting mers. The payroll-system software, which in the long-term cost of poor quality. Third, handles roughly 10,000 employees, and con- a side effect of pair programming is a high sists of 2,000 classes and 30,000 methods, order of staff cross training, which removes went into operation in May 1997, almost on additional long-term costs from develop- schedule.9 ment. As Beck writes, “Even if you weren’t In the online survey of professional pair more productive, you would still want to Figure 1. Comparison programmers, we found similar experiences. pair, because the resulting code quality is so of pair programmers’ For example, one respondent wrote: much higher.”10 and individuals’ Many people reject the idea of pair pro- project completion I strongly feel pair programming is the gramming because they assume that putting times. (Data entry primary reason our team has been suc- two programmers on a job that one can do problems prevented cessful. It has given us a very high level of will increase programmer hours 100%. In accurate recording of code quality (almost to the point of zero our experiment, however, after the initial the completion times defects). The only code we have ever had adjustment period, the total for Program 4.) errors in was code that wasn’t pair pro- programmer hours the pairs grammed.… we should really question a spent on each assignment de- situation where it isn’t utilized. creased dramatically (see Fig- Our university experiment produced ure 1). If we had required the quantitative results similar to industry re- individuals to spend addi- Individuals sults. The students completed four assign- tional time improving their Pairs ments over a period of six weeks. The pairs code to the level of the pairs’ always passed more of the automated post- code, the individuals would 100% development test cases (see Table 1). Their have taken even more time results were also more consistent, while the than the pairs. By working in 80% individuals varied more about the mean. tandem, the pairs completed Some individuals didn’t hand in a program their assignments 40% to 60% or handed it in late; pairs handed in their 50% faster. assignments on time. We attribute the pairs’ In today’s market, getting a 40% punctuality to positive pressure the part- quality product out as quickly ners exert on each other. They admit to as possible is a competitive ad- 20% working “harder and smarter” because vantage that might even mean 0% they don’t want to let their partner down. survival. Fixing defects after Program 1 Program 2 Program 3 Without this pressure, individuals don’t release to customers can cost perform as consistently. far more than finding and fix- In addition to the development-quality ing them during development.

July/August 2000 IEEE SOFTWARE 23 The benefits of getting a product out faster, waiting. Because of this peer pressure, reducing maintenance expenses, and im- pairs usually have a stronger motivation to Unlike many proving customer satisfaction outweigh any complete the task during the session; there- programmer-hour increase that pair pro- fore, they work with much greater focus techniques grammers might incur. and intensity than individuals. put forth to For several reasons, programmer-hours improve do not double with pair programming as Pair Satisfaction one might expect. First, collaboration im- Unlike many techniques put forth to im- software proves the problem-solving process. As a re- prove software quality and productivity, quality and sult, far less time is spent in the chaotic, pair programming is one that programmers time-consuming compile and test phases. actually enjoy. Pair programming improves productivity, Said one of the students in the experiment: their job satisfaction and overall confidence in their work. In the online survey of pro- pair When I worked on the machine as the fessional pair programmers, 96% stated programming driver, I concentrated highly on my work. that they enjoyed their job more than when I wanted to show my talent and quality is one that they programmed alone. We surveyed the work to my partner. When I was doing it, 41 collaborative programmers in the uni- programmers I felt more confident. In addition, when I versity experiment six times. Consistently, had a person observing my work, I felt actually enjoy. more than 90% stated that they enjoyed that I could depend on him, since this collaborative programming more than solo person cared about my work and I could programming. Additionally, virtually all the trust him. If I made any mistakes, he surveyed professional programmers stated would notice them, and we could have a that they were more confident in their solu- high-quality product. When I was the tions when they pair programmed. Almost nondriver, I proofread everything my 95% of the students echoed this statement. partner typed. I felt I had a strong re- A natural correlation exists between these sponsibility to prevent any errors in our two measures of satisfaction. That is, the work. I examined each line of code very pairs enjoy their work more because they are carefully, thinking that if there were any more confident in their work. Someone is defects in our work, it would be my fault. there to help them if they are confused or un- Preventing defects is the most important knowledgeable. They can bounce ideas off a contribution to the team, and it put a bit friend. They spend more time doing chal- of pressure on me. lenging design and less time doing annoying Additionally, pairs find that by pooling debugging. They leave each session with an their joint knowledge, they can conquer al- exhilarated, we-nailed-that-one feeling. In- most any technical task immediately. In deed, having engaged in pair programming teaching the university class that partici- ourselves, we agree completely that it is far pated in the experiment, the instructor no- more enjoyable than individual program- ticed that individual workers asked two or ming. We too have experienced the shared three times more technical questions than euphoria that follows the successful comple- did collaborative workers. While waiting tion of a collaborative task. for the answers to these questions, these stu- Although most programmers enjoy pair dents were generally unproductive. We programming, sometimes they have trouble would expect this situation to translate to a working with a particular partner. The diffi- professional environment. culty often arises from being paired with As mentioned earlier, pair programmers someone with excess ego—the my-way-or- put pressure on each other to perform, the-highway attitude. Or the problem might keeping their partner focused and on task. be too little ego—partners who have trouble Programmers have told us that even if they asserting themselves and thus contribute lit- come to work after a bad night or are pre- tle. The majority of participants in our occupied with other thoughts, their partner study and in our survey were self-selected draws their attention to the task at hand. pair programmers. Further study is needed They are less likely to spend time talking to examine the eventual satisfaction of pro- on the telephone, reading and answering e- grammers forced to pair program despite mail, or surfing the Web if their partner is their resistance.

24 IEEE SOFTWARE July/August 2000 My First Pair-Programming Experience by Ron Jeffries We hadn’t been programming more than a few minutes Like most programmers, I had done some pair program- when the youngster asked me why I was doing what I was do- ming, usually when working on something particularly tricky or ing. Sure enough, I was off on a bad track. I went another during some difficult debugging sessions. Although Ward Cun- way. Then the whippersnapper reminded me of the correct ningham had recommended full-time pair programming a few method name for whatever I was mistyping at the time. Pretty times, my first experience with “real” pair programming came soon, he was suggesting what I should do next, meanwhile on the C3 [Chrysler Comprehensive Compensation] project, calling out my every formatting error and syntax mistake. where I was coach. I’m not entirely stupid. I noticed very quickly that this most I was sitting with one of the least-experienced developers, junior of programmers was actually helping me! Me! Can you working on some fairly straightforward task. Frankly, I was believe it? Me! Since then, that’s been my experience every thinking to myself that with my great skill in Smalltalk, I would time in pair programming. Having a partner makes me a better soon be teaching this young programmer how it’s really done. programmer. Ward was right—as usual.

arge-group software projects are shop, Ablex Publishing, New York, 1991, pp. 36–64. prone to peculiar difficulties. As the 5. G.M. Weinberg, The Psychology of Computer Pro- well-known Brooks’s law states, gramming Silver Anniversary Edition, Dorset House, L New York, 1998. “Adding manpower to a late software proj- 6. L.A. Williams and R.R. Kessler, “All I Ever Needed to ect makes it later.”11 The logic behind this Know about Pair Programming I Learned in Kinder- garten,” Comm. ACM, Vol. 43, No. 5, 2000, pp. law focuses on intercommunication effort: 108–114. 7. T. DeMarco and T. Lister, Peopleware, Dorset House, In tasks requiring communication among New York, 1977. the subtasks, the effort of communication 8. J.R. Katzenbach and D.K. Smith, The Wisdom of must be added to the amount of work to Teams: Creating the High-Performance Organization, Harper Business, New York, 1994. be done.... The added burden of communi- 9. A. Anderson et al., “Chrysler Goes to ‘Extremes’,” Dis- cation is made up of two parts, training tributed Computing, Oct. 1998, pp. 24–28. and intercommunication.... If each part of 10. K. Beck, Extreme Programming Explained: Embrace Change, Addison Wesley Longman, Reading, Mass., the [n] task[s] must be separately coordi- 2000. nated with each other part, the [intercom- 11. F.P.J. Brooks, The Mythical Man-Month, Addison- munication] effort increases as n(n + 1)/2.11 Wesley, Reading, Mass., 1975. Integrating the partitioned tasks of pro- grammers requires this extra intercommuni- cation effort. Pair programming can halve About the Authors the number of separate tasks to be integrated, and thus we anticipate that large groups con- Laurie Williams is a faculty member at North Carolina State University. Her research interests are software engineering, software process, collaborative programming, and sisting of pair-programming teams should e-commerce. She received a BS in industrial engineering from Lehigh University, an MBA from fair much better. We would like to run an- Duke University, and a PhD in from the University of Utah. Contact her at other university study to analyze the effect of [email protected]. pair programming on larger groups. Finally, we would like to see the same ex- periments applied in an industrial setting— Robert R. Kessler is a professor and chairman of the Department of Computer Science of the University of Utah. In the early 1990s, he founded the Center for Software Science, a Utah perhaps with part of a larger development Center of Excellence. He recently completed seven years as coeditor in chief of the International team. Anyone interested in running such an Journal of Lisp and Symbolic Computation. His research interests include agents, software engi- experiment should contact Laurie Williams neering, distributed systems, and visual programming. Contact him at [email protected]. ([email protected]).

Ward Cunningham is a founder and owner of Cunningham & Cunningham, a consulting References firm. Among his contributions to the developing practice of object-oriented programming, he cre- 1. L.L. Constantine, Constantine on Peopleware, Yourdon ated the CRC design method, which helps teams find core objects for their programs. He is active Press, Englewood Cliffs, N.J., 1995. in and has served as program chair of its Pattern Languages of Programs Con- 2. J.T. Nosek, “The Case for Collaborative Programming,” ference. Contact him at [email protected]. Comm. ACM, Vol. 41, No. 3, 1998, pp. 105–108. 3. J.O. Coplien, “A Development Process Generative Pat- tern Language,” Pattern Languages of Program Design, J.O. Coplien and D.C. Schmidt, eds., Addison-Wesley, Ron Jeffries is an independent consultant. He has been developing software since 1961, when he accidentally got a Reading, Mass., 1995, pp. 183–237. summer job at the Strategic Air Command headquarters, where they accidentally gave him a Fortran manual. He and his 4. N.V. Flor and E.L. Hutchins, “Analyzing Distributed teams have built operating systems, language compilers, relational and set-theoretic database systems, and manufacturing Cognition in Software Teams: A Case Study of Team control and applications software, producing about a half-billion dollars in revenue—and he wonders why he didn’t get Programming during Perfective ,” any of it. For the past few years, he has been learning, applying, and teaching the eXtreme Programming discipline. Con- Proc. Empirical Studies of Programmers: Fourth Work- tact him at [email protected].

July/August 2000 IEEE SOFTWARE 25