The Costs and Benefits of Pair Programming Alistair Cockburn Laurie Williams Humans and Technology University of Utah Computer Science 7691 Dell Rd 50 S. Central Campus #3190 Salt Lake City, UT 84121, USA Salt Lake City, UT 84112, USA [email protected] 801.947.9277 [email protected] 435.649.7931 “Only if the various principles - names, However, convention speaks against having two definitions, intimations and perceptions - are people work together to develop code -- having laboriously tested and rubbed one against the “two do the work of one”, as some people see it. other in a reconciliatory tone, without ill will · Managers view programmers as a scarce during the discussion, only then will insight and resource, and are reluctant to "waste" such by reason radiate forth in each case, and achieve doubling the number of people needed to what is for man the highest possible force...” develop a piece of code. -Plato · Programming has traditionally been taught “Knowledge is commonly socially constructed, and practiced as a solitary activity. through collaborative efforts toward shared objectives or by dialogues and challenges · Many experienced programmers are very brought about by differences in persons' reluctant to program with another person. perspectives." -Salomon [1] Some say their code is "personal," or that another person would only slow them down. ABSTRACT Others say working with a partner will cause Pair or collaborative programming is where two trouble coordinating work times or code programmers develop software side by side at versions. one computer. Using interviews and controlled At the same time: experiments, the authors investigated the costs and benefits of pair programming. They found · Several well-respected programmers prefer that for a development-time cost of about 15%, working in pairs, making it their preferred pair programming improves design quality, programming style [2] [3]. reduces defects, reduces staffing risk, enhances · Seasoned pair programmers describe working technical skills, improves team communications in pairs as "more than twice as fast" [3]. and is considered more enjoyable at statistically · Qualitative evidence suggests the resulting significant levels. design is better, resulting in simpler code, Keywords easier to extend. pair programming, collaborative programming, · Even relative novices contribute to an expert's extreme programming, code reviews, people programming, according to interviews. factors, collaborative programming This raises some provocative questions. Is pair 1 INTRODUCTION programming really more effective than solo programming? What are the economics? What When pair programming, two programmers work about the people factor - enjoyment on the job? collaboratively on the same algorithm, design or programming task, sitting side by side at one Based on recent interest in pair programming, the computer. This practice has been nominated authors examined interview and experimental several times in the last decades as an improved data to understand the costs and benefits of way of developing software [2] [3]. practice. This paper presents the results of that Page 1 investigation. Previous publications [4] [5] [6] more confident in the correctness of the results. have demonstrated that pair programming is When we finally made it to the first checkpoint beneficial. The purpose of this paper is to re- application, we zoomed through QA with hardly a examine these results and to further explain why hitch. Everyone, myself included, was amazed that pair programming is beneficial. it didn't take weeks to debug, especially given that one of the trees had recently spent SIX WEEKS in 2 A PROJECT EXPERIENCE QA hell. It was obvious that the pairs had dramatically reduced the defect rate. The following excerpt comes from an experienced programmer describing his As the merge progressed the pairs worked together organization’s first venture into pair even more closely. programming. It reveals many features of the pair ... As each subsystem was complete the pairs programming experience, as will be discussed in would get rearranged based on knowledge of the next task. This slowed things down because the this paper. new pairs would have to spend time getting in In early December my team began a high-risk phase with one another before working effectively. activity: it involved touching just about every file, But by August the pairs were fairly well cemented, merging the code together, and trying to keep to the point where they would routinely speak for everything working. Furthermore, one tree involved each other in our twice-weekly team meetings. fairly deep rearchitecture. So the merge would be Subsequent releases, both internal and external, composed of both utter tedium and massive thought went smoothly and we rarely hit massive show- effort. stopper bugs. The continual review caught many The staff agreed with my points that pair serious issues midstream, including some major programming: design problems that hadn't been noticed before. - Should significantly reduce the risk of subtle I wasn't involved in a pair until fairly late in the errors that would make debugging excruciating; game. Once my partner and I synchronized our brains, it was a great experience. - Would give us a much broader code review than we'd ever had; and He was relatively junior, but he asked the right questions and, by struggling for answers, we usually - Would provide an opportunity to communicate forced ourselves to discover the best solution to knowledge between coders. each problem. For the first few weeks, things didn't work out as ... The team members decided to do it for envisioned. Instead of doing side-by-side pair themselves. None of my pontification had as much programming, the first few people did what I called effect as experience. "partner programming": they coded individually for awhile, and then reviewed the changes with their 3 INVESTIGATIVE PATHS partner before checking-in the modifications. They We explore eight paths of software engineering reported that they were catching errors early. This was encouraging, but I was disappointed that they and organizational effectiveness. Surprisingly, weren't working together consistently. all paths point to pair programming. These investigative paths are briefly described: But about four months into the merge, I began to notice that things were changing. One pair in Economics. A recent controlled experiment [4] particular spent their whole day together, doing found only a small development cost for adding honest-to-goodness pair programming, and the other two pairs were getting much closer to that the second person. However, the resulting code ideal. In discussions it was clear that they knew why also had fewer defects. The defect removal the change was happening. It simply worked better! savings should more than offsets the development They discovered that it took longer to work cost increase. independently and then review the changes, since Satisfaction. People working in pairs found the the review process involved teaching your partner everything you had learned in making the changes. experience more enjoyable than working alone. And that took almost as long as making the Design quality. The study [4] also found that the changes to begin with. By working together they could avoid "doing it twice", the coding went faster pairs produced shorter programs than their solo due to the two-brain effect, and they were much peers, indicating superior designs. Interviewees Page 2 made the same comments. “jelling” assignment), together the pairs only Continuous Reviews. Pair programming’s spent about 15% more time on the program than shoulder-to-shoulder technique serves as a the individuals [4]. Development costs certainly do not double with pair programming! continual design and code review, leading to most efficient defect removal rates. Relative Time: One Individual vs Two Problem solving. Interview participants Collaborators constantly refer to the team's ability to solve 200.0% "impossible" problems faster. 150.0% Learning. Pair programmers repeatedly cite how 100.0% much they learn from each other. 50.0% Team Building and Communication. Interview 0.0% participants describe that people learn to discuss Program 1 Program 2 Program 3 and work together. This improves team One Individual Two Collaborators communication and effectiveness. Staff and Project Management. Since multiple Figure 1: Programmer Time people have familiarity with each piece of code, Significantly, the resulting code has about 15% pair programming reduces staff-loss risk. fewer defects [4]. (These results are statistically In this paper, each of these investigative paths significant.) Figure 2 shows the post- will be further discussed -- reviewing the development test cases the students passed for supporting statistical and interview data and each program – essentially the percentage of the highlighting the costs and the benefits. instructor’s test cases passed. 4 ECONOMICS Post Development Test Cases Passed The affordability of pair programming is a key issue. If it is much more expensive, managers 100.0% simply will not permit it. Skeptics assume that 80.0% incorporating pair programming will double code 60.0% development expenses and critical manpower 40.0% needs. Along with code development costs, 20.0% however, other expenses, such as quality 0.0% Program 1 Program 2 Program 3 assurance and field support costs must also be considered. IBM reported spending about $250 Individuals Collaborators