Jump to content

Pair programming

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by 50.179.159.178 (talk) at 03:48, 15 December 2014 (→Remote pair programming: Mention SubEthaEdit as an old, popular editor for distributed pair programming.). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Pair programming

Pair programming (sometimes referred to as peer programming) is an agile software development technique in which two programmers work as a pair together on one workstation. One, the driver, writes code while the other, the observer, pointer or navigator,[1] reviews each line of code as it is typed in. The two programmers switch roles frequently.

While reviewing, the observer also considers the "strategic" direction of the work, coming up with ideas for improvements and likely future problems to address. This frees the driver to focus all of his or her attention on the "tactical" aspects of completing the current task, using the observer as a safety net and guide.

Benefits

  • Economics: Pairs spend about 15% more time on programs than individuals. However, the resulting code has about 15% fewer defects. Along with code development time, other factors like field support costs and quality assurance also affect the expenses. IBM reported spending about “$250 million repairing and reinstalling fixes to 30,000 customer-reported problems”. Pair programming significantly reduces these expenses by reducing the defects in the programs.[2]
  • Design Quality: A system with two programmers possesses greater potential for the generation of more diverse solutions to problems for three reasons: (1) the programmers bring different prior experiences to the task; (2) they may access information relevant to the task in different ways; (3) they stand in different relationships to the problem by virtue of their functional roles. In the attempt to share goals and plans, the programmers must overtly negotiate a shared course of action when a conflict arises between them. In doing so, they consider a larger number of ways of solving the problem than a single programmer alone might do. This significantly improves the design quality of the program as it reduces the chances of selecting a poor method.[3]
  • Satisfaction: In an online survey of pair programmers, 96% of them stated that they enjoyed their work more than when they programmed alone. Additionally, 95% of the surveyed programmers stated that they were more confident in their solutions when they pair programmed. A correlation exists between satisfaction among programmers and their confidence in the codes i.e. the pairs enjoy their work more because they are more confident in it.[4]
  • Learning: Knowledge is constantly shared between pair programmers, from tips on programming language rules to overall design skill.[5] In "promiscuous pairing", each programmer communicates and works with all the other programmers on the team rather than pairing only with one partner, which causes knowledge of the system to spread throughout the whole team.[2] Pair programming allows the programmers to examine their partner's code and provide feedback which is necessary to increase their own ability to develop monitoring mechanisms for their own learning activities.[5]
  • Team Building and communication: Pair programming allows team members to share problems and solutions quickly making them less likely to have hidden agendas from each other. This helps pair programmers to learn to communicate more easily. “This raises the communication bandwidth and frequency within the project, increasing overall information flow within the team.”[2]

Studies

There are both empirical studies and meta-analyses of pair programming. The empirical studies tend to examine the level of productivity and the quality of the code, while meta-analyses may focus on biases introduced by the process of testing and publishing.

Empirical studies

Williams: error reduction with increased effort

The Economist noted,

Laurie Williams of the University of Utah in Salt Lake City has shown that paired programmers are 15% slower than two independent individual programmers, while "error-free" code increased from 70% to 85%. Since testing and debugging are often many times more costly than initial programming, this is an impressive result.[6] Pairs typically consider more design alternatives than programmers working alone, and arrive at simpler, more maintainable designs; they also catch design defects early.[7]

The Williams study showed an improvement in correctness of around 15%, and a 20%–40% decrease in time; however the study also noted a 15%–60% increase in effort (as measured by total programmer-hours). Williams also cites an earlier study (Nosek 1998) which also had a 40% decrease in time for a 60% increase in effort.

Lui: comparing pairs to working alone

A study (Lui 2006) compared novice pairs to novices working alone, and expert pairs to experts working alone. Lui found that novice–novice pairs experienced greater productivity gains than a lone novice when compared to expert–expert pairs and a lone expert.[8]

Arisholm: complex systems more correct; simple systems faster

A larger study (Arisholm et al. 2007) found a 48% increase in correctness for complex systems, but no significant difference in time. Simple systems enjoyed a 20% decrease in time, but no significant difference in correctness. Overall, there was no reduction in time or increase in correctness, but rather an 84% increase in effort.[9][10]

Lui, Chan, and Nosek: design tasks

Lui, Chan, and Nosek performed two experiments in design tasks: (1) Procedural Solution Tasks; and (2) Deductive Problem Solving. In 2002–2003, 15 part-time third year undergraduate students at the Hong Kong Polytechnic University, Hong Kong and full-time industrial programmers were invited to complete 15 multiple-choice questions on five procedural algorithmic tasks. “Analyzing a flowchart is a fundamental skill required in programming design”. The key processes of Coordinate Measuring Machines, extreme programming and pair programming were introduced to the students before the experiment. In the controlled experiment, the subjects were randomly divided into five pairs and five individuals. Because of the “small sample size”, the Wilcoxon rank sum test was used to “statistically evaluate the results”. The pairs outperformed the individuals significantly in both the tests for elapsed time and number of resubmissions with a p-value of .03. Ten of the fifteen subjects agreed to participate in the second experiment. In this experiment, the students were asked to solve deduction problems that help to examine a developer’s ability to “cope with complexity”. The subjects first worked in pairs on one problem and then worked individually on the next problem. The Wilcoxon rank sum test proved that the pairs outperformed individuals with respect to elapsed time and number of resubmissions with a p-value of .014 and .01, respectively.[11]

John T. Nosek: code quality

Nosek performed an experiment on 15 full-time system programmers from a program trading firm. Ten programmers worked in pairs whereas five programmers worked individually. “The subjects were asked to write a script that performs a database consistency check (DBCC) with the output for errors to be written to a file” and were given 45 minutes for the task. The groups were scored on the readability and functionality of the code produced. The pairs scored 30% higher on the readability of code and 23% higher on the functionality of code. These results provided evidence that pair programming improves the problem solving process.[12]

Jerzy R. Nawrocki: programmer effort

Nawrocki performed an experiment on 15 fourth-year students to evaluate the relative effort between pair programmers and solo programmers. He used the concept of “Relative Effort Afforded by Pairs” (REAP) for his experiments. The group was divided into five pairs and five individuals. All the programmers had “two years of formal study in C and C++”. The subjects were asked to write four programs. “These were programs for finding the mean and standard deviation of samples of numerical data, finding the linear regression parameters, counting the number of lines in a program and counting the total program LOC.” His experiments revealed that the individual programmers and the pairs took the same amount of time to finish the first three programs which meant that REAP was 100%. Thus, Nawrocki concluded that pair programming was not as efficient as had been reported by Laurie Williams and John Nosek.[13]

Meta-analyses

A full-scale meta-analysis of pair programming experimental studies was conducted in 2007. This analysis included 18 studies on pair programming. Three separate meta-analyses were conducted for the important cost drivers such as quality, duration and effort. The meta-study found that pair programming has a “medium positive” effect on the duration of code development and produces marginal positive effects on code quality, but that pair programming has a “medium negative” effect on the development effort; that is, it is significantly more expensive than solo programming. The authors suggest that studies of pair programming suffer from publication bias whereby studies that would not show that pair programming is beneficial were not undertaken, not submitted for publication, or not accepted for publication. They conclude that "you cannot expect faster and better and cheaper." [14]

This study suggests that even though coding is often completed faster than when one programmer works alone, the total amount of man-hours (the product of the number of programmers and the time spent) increases. A manager would have to balance faster completion of the work and reduced testing and debugging time against the higher cost of coding. The relative weight of these factors can vary by project and task. The benefit of pairing is greatest on tasks that the programmers do not fully understand before they begin: that is, challenging tasks that call for creativity and sophistication.[8] On simple tasks, which the pair already fully understands, pairing results in a net drop in productivity.[8][9] Productivity can also drop when novice–novice pairing is used without sufficient availability of a mentor to coach them.[15]

The matter of the superiority of pair programming over solo programming involves various factors like the experience and skill of the programmers and the complexity of the task. Pair programming could be helpful for attaining high quality and correctness on complex programming tasks, but it would also increase the development effort (cost) significantly. Pair programming may reduce the code development time but also risks reducing the quality of the program. Thus the meta-analysis concluded that "pair programming is not uniformly beneficial or effective".[14]

Replicable experiment

Although there are many scholarly experiments related to pair programming, few have been successfully replicated by other researchers. This might have continued to keep pair programming controversial. However, in 2013, Giri and Soni [16] replicated the experiment related to pair programming done by Kim Man Lui [17] in 2006. Giri and Soni reproduced a similar result.

Indicators of non-performance

There are a few indicators that a pair is not performing well:

  • Disengagement may present as one of the members physically withdraws away from the keyboard, accesses email, or even falls asleep.
  • The "Watch the Master" phenomenon can arise if one member is more experienced than the other. In this situation, the junior member may take the observer role, deferring to the senior member of the pair for the majority of coding activity. This can easily lead to disengagement.
  • Silence immediately indicates a lack of collaboration.[18]

Pairing variations

There are 3 main combinations used when pairing:

  • Expert–Expert pairing may seem to be the obvious choice for the highest productivity and can produce great results, but it often yields little insight into new ways to solve problems, as both parties are unlikely to question established practices. [8]
  • Expert–Novice pairing creates many opportunities for mentoring of the novice by the expert. This can also lead to new solutions or new ideas, as the novice is more likely to question established practices. However this can sometimes lead to "watch the master" or if the novice feels they have nothing to add and being a burden, they may start to clear one's throat to get more time to think when asked a question. [19]
  • Novice–Novice pairing would seem the least optimal for productivity and quality, however the results can often be significantly better than two novices working independently. This pairing is often used in academic environments.[2]

Remote pair programming

Remote pair programming, also known as virtual pair programming or distributed pair programming, is pair programming in which the two programmers are in different locations,[20] working via a collaborative real-time editor, shared desktop, or a remote pair programming IDE plugin. Remote pairing introduces difficulties not present in face-to-face pairing, such as extra delays for coordination, depending more on "heavyweight" task-tracking tools instead of "lightweight" ones like index cards, and loss of verbal communication resulting in confusion and conflicts over such things as who "has the keyboard".[21]

Tool support could be provided by:

See also

References

  1. ^ Williams, Laurie (2001). "Integrating Pair Programming into a Software Development Process" (PDF). 14th Conference on Software Engineering Education and Training: abstract. {{cite journal}}: Unknown parameter |nopp= ignored (|no-pp= suggested) (help)"One of the programmers, the driver, has control of the keyboard/mouse and actively implements the program. The other programmer, the observer, continuously observes the work of the driver to identify tactical (syntactic, spelling, etc.) defects, and also thinks strategically about the direction of the work."
  2. ^ a b c d Cockburn, Alistair; Williams, Laurie (2000). "The Costs and Benefits of Pair Programming" (PDF). Proceedings of the First International Conference on Extreme Programming and Flexible Processes in Software Engineering (XP2000).
  3. ^ Flor, N.V. and E.L. Hutchins. Analyzing Distributed Cognition in Software Teams: A Case Study of Team Programming During Perfective Software Maintenance. Proceedings of the Fourth Annual Workshop on Empirical Studies of Programmers. 1991: Ablex Publishsing Corporation.
  4. ^ Laurie Williams, Robert R. Kessler, Ward Cunningham, Ron Jeffries. “Strengthening the Case for Pair Programming.” IEEE Software. IEEE Software, July–Aug. 2000. Web. 4 October 2013
  5. ^ a b Richard L. Upchurch, Laurie Williams. “In Support of Student Pair Programming.” ACM SIGCSE. ACM Publications, March 2001. Web. 4 October 2013
  6. ^ "Agility counts". The Economist. September 20, 2001..
  7. ^ Williams, Laurie; Kessler, Robert (2003). Pair Programming Illuminated. Addison-Wesley. pp. 27–28. ISBN 0-201-74576-3. With pair programming, 'four eyeballs are better than two,' and a momentous number of defects are prevented, removed right from the start. These continual reviews outperform traditional, formal reviews in their defect-removal speed.
  8. ^ a b c d Lui, Kim Man (September 2006). "Pair programming productivity: Novice–novice vs. expert–expert" (PDF). International Journal of Human–Computer Studies. 64 (9): 915–925. doi:10.1016/j.ijhcs.2006.04.010. Retrieved 2012-11-18.
  9. ^ a b Arisholm, Erik; Hans Gallis; Tore Dybå; Dag I.K. Sjøberg (February 2007). "Evaluating Pair Programming with Respect to System Complexity and Programmer Expertise". IEEE Transactions on Software Engineering. 33 (2): 65–86. doi:10.1109/TSE.2007.17. Retrieved 2008-07-21.
  10. ^ Aranda, Jorge (2007-03-12). "Pair programming evaluated". Retrieved February 7, 2008.
  11. ^ Kim Man Lui, Keith C.C. Chan, John Teofil Nosek. “The Effect of Pairs in Program Design Tasks”. IEEE Transactions on Software Engineering. IEEE Computer Society, March–April 2008. Web. 4 October 2013
  12. ^ John T. Nosek. “The Case for Collaborative Programming”. Communications of the ACM. ACM Publications, March 1998. Web. 4 October 2013
  13. ^ Kim Man Lui, Keith C.C. Chan. “Pair Programming Productivity: Novice–Novice vs Expert–Expert”. International Journal of Human Computer Studies. Academic Press Inc., September 2006. Web. 4 October 2013
  14. ^ a b Hannay, Jo E.; Tore Dybå; Erik Arisholm; Dag I.K. Sjøberg (July 2009). "The Effectiveness of Pair Programming: A Meta-Analysis". Information and Software Technology. 51 (7): 1110–1122. doi:10.1016/j.infsof.2009.02.001.
  15. ^ Stephens, Matt; Doug Rosenberg. "Will Pair Programming Really Improve Your Project?". Retrieved 28 May 2011.
  16. ^ Giri, Manisha (June 2013). "Effectiveness of Software Development Process Using Programmer Ranker Algorithm in Pair Programming" (PDF). International Journal of Engineering Sciences and Research Technology. 2 (6): 1524–1535. Retrieved 2013-10-30.
  17. ^ Lui, Kim Man (2010). "Pair Programming: Issues and Challenges" (PDF). Agile Software Development: Current Research and Future Directions.: 143–163. Retrieved 2013-10-30.
  18. ^ http://www.agilesherpa.org/agile_coach/engineering_practices/pair_programming/
  19. ^ Williams, L. and Kessler, R. (2003). Pair Programming Illuminated. Boston: Addison-Wesley Professional.{{cite book}}: CS1 maint: multiple names: authors list (link)
  20. ^ Flor, Nick (2006). Globally distributed software development and pair programming. Communication of the ACM, 49, 57–58.
  21. ^ Schümmer, Till; Stephan Lukosch (September 2009). "Understanding Tools and Practices for Distributed Pair Programming" (PDF). Journal of Universal Computer Science. 15 (16): 3101–3125. Retrieved 2010-04-30.
  22. ^ Agile Ajax: Pair Programming with VNC
  23. ^ Pair Programming – The Ultimate Setup and the other options we tried. – Jonathan Cogley's Blog
  24. ^ Ola Lindberg › Computer ergonomics and pair programming
  • wikiHow: How to Pair Program How-to guide; contains common wisdom on how to make pair programming work.
  • PairWithUs A collection of videos showing pair programming in action.
  • Airpair An online marketplace for finding expert programmers to pair with across a wide range of technologies.
  • Codementor A list of code mentors available to pair program remotely with via screen sharing and video chat.

Programs and plug-ins to support remote pair programming

Retrieved from "https://en.wikipedia.org/w/index.php?title=Pair_programming&oldid=638142608"