Pair programming is an agile software development technique in which two programmers work together at one workstation. One, the driver, writes code while the other, the observer or navigator, 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.
- 1 Benefits
- 2 Studies
- 3 Non-Performing Indications
- 4 Variants
- 5 See also
- 6 References
- 7 External links
Programmers working in pairs usually produce shorter programs, with better designs and fewer bugs, than programmers working alone. Studies have found reduction in defect rates of 15% to 50%, varying depending on programmer experience and task complexity. Pairs typically consider more design alternatives than programmers working alone, and arrive at simpler, more maintainable designs; they also catch design defects early. Pairs usually complete work faster than one programmer assigned to the same task. Pairs often find that seemingly "impossible" problems become easy or even quick, or at least possible to solve when they work together.
Knowledge passes between pair programmers as they work. They share knowledge of the specifics of the system, and they pick up programming techniques from each other. New hires quickly pick up the practices of the team and learn the specifics of the system. With "promiscuous pairing"—each programmer cycling through all the other programmers on the team rather than pairing only with one partner—knowledge of the system spreads throughout the whole team, reducing risk to management if one programmer leaves the team.
Pairing usually brings improved discipline and time management. Programmers are less likely to skip writing unit tests, spend time web-surfing or on personal email, or cut corners when they are working with a pair partner. The pair partner "keeps them honest". People are more reluctant to interrupt a pair than they are to interrupt someone working alone.
||This section may require copy editing for organization. (November 2012)|
There are both empirical and meta-analyses studies 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.
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."
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, as well as expert pairs to experts working alone. Lui found that novice–novice pairs experienced greater productivity gains against novice alone when compared to expert–expert pairs against expert alone.
Arisholm: complex systems more correct; simple systems faster
A larger study (Arisholm et al. 2007) had 48% increase in correctness for complex systems, but no significant difference in time. Simple systems enjoyed 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.
Lui, Chan, and Nosek: design tasks
Lui, Chan, and Nosek (2008) shows that pair programming outperforms for design tasks.
A full-scale meta-analysis of pair programming experimental studies, from before or during 2007, (Hannay et al. 2009) confirms "that you cannot expect faster and better and cheaper." Higher quality for complex tasks costs higher effort, while reduced duration for simpler tasks suffers from lower quality – the meta-analysis "suggests that pair programming is not uniformly beneficial or effective".
However, a 2007 meta-analysis concluded that "pair programming is not uniformly beneficial or effective" because many other factors besides the choice of whether to use pair programming have large effects on the outcome of a programming task. The meta-study found that pair programming tends to reduce development time somewhat and produces marginal positive effects on code quality, but that pair programming requires significantly more developer 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 either not undertaken, not submitted for publication, or not accepted for publication. They conclude that "you cannot expect faster and better and cheaper."
This study suggests that even though coding is often completed faster than when one programmer works alone, the total amount of programmer-hours (number of programmers × time spent) increases. A manager needs 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 from project to project and task to 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. On simple tasks, which the pair already fully understands, pairing results in a net drop in productivity. Productivity can also drop when novice-novice pairing is used without sufficient availability of a mentor to coach them.
There have been a number of experiments that have attempted to measure the cost/benefit of pair programming; as pointed out in the previous section the results have been inconclusive.
Replication is the process of repeating an experiment to check whether the original results occur. Replicating one or more of the previous experiments could provide some conclusive evidence for the effects of pair programming.
Many pair programming experiments are not highly reproducible, However, in 2013, Giri and Soni  replicated the experiment (in which a horse-trading problem solved by two groups: individual programmers and paired programmers) proposed and done by Kim Man Lui  in 2006. Giri and Soni reproduced the similar result. The replication signifies the difference between pairs and solos.
There are a few indicators that a pair is not performing well:
- Disengagement – One of the members physically moves their chair away from the keyboard, or starts working on their email, etc. Sometimes this can be as extreme as one member falling asleep.
- Watch the Master – Sometimes one member will be more experienced than the other. There is a temptation to defer to the more senior member, and the less senior will be relegated to observer status. This will often lead to disengagement.
- Silence – Pairs cannot work together if they are not talking to each other.
Remote pair programming
Remote pair programming, also known as virtual pair programming or distributed pair programming, is pair programming where the two programmers are in different locations, 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 non-verbal communication resulting in confusion and conflicts over such things as who "has the keyboard".
Tool support is provided either:
- Whole-screen sharing software, such as Microsoft Lync, VNC/RealVNC, or Skype™
- Terminal multiplexers, such as
- Specialized distributed editor tools (such as Gobby, Saros, XPairtise, Floobits or Visual Studio Anywhere).
- Williams, Laurie (2001). "Integrating Pair Programming into a Software Development Process" (PDF). 14th Conference on Software Engineering Education and Training: abstract."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."
- 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).
- Canfora, Gerardo; Aniello Cimitile, Felix Garcia, Mario Piattini, Corrado Aaron Visaggio (2007). "Evaluating performances of pair designing in industry". The Journal of Systems and Software 80 (80): 1317–1327. doi:10.1016/j.jss.2006.11.004. CiteSeerX: 10.1.1.101.9212.
- "Agility counts". The Economist. September 20, 2001..
- 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."
- Williams, Laurie; Kessler, Robert (2003). Pair Programming Illuminated. Addison-Wesley. p. 26. ISBN 0-201-74576-3. "Collaborative teams consistently report that together they can evolve solutions to unruly or seemingly impossible problems. ... The driver might actually be working out a design or implementing a part of the problem, realizing that he or she may ultimately come to a dead end in the problem resolution. The navigator, while watching the driver's partial design or implementation, begins thinking about the next step. When the driver hits the dead end, the navigator is often prepared to take over and lead the way. Often, the cycle continues until the problem is solved."
- Williams, Laurie; Kessler, Robert (2003). Pair Programming Illuminated. Addison-Wesley. p. 29. ISBN 0-201-74576-3. "Knowledge is constantly being passed between partners, from tool usage tips to design and programming idioms. The partners take turns being the teacher and the student. Even unspoken skills and habits cross partners."
- Williams, Laurie; Kessler, Robert (2003). Pair Programming Illuminated. Addison-Wesley. p. 112. ISBN 0-201-74576-3. "[Expert-novice pairing] can even be valuable for novices who are novices only in the sense that they haven't been with their team for very long. ... Watching and then doing with an expert by your side can greatly reduce the time it would require to learn 'the right way' of working with the team. It really helps when the newbie works with many of the experts (or with any team member) so he or she can learn about many different aspects of the system."
- Williams, Laurie; Kessler, Robert (2003). Pair Programming Illuminated. Addison-Wesley. p. 23. ISBN 0-201-74576-3. "Two people working in a pair treat their shared time as more valuable. They tend to cut phone calls short; they don't check e-mail messages or favorite Web pages; they don't waste each other's time." (Ward's Wiki 1999, contributed by Paul Chisholm).
- Beck, Kent (2000). Extreme Programming Explained. Addison-Wesley. p. 102. ISBN 978-0201-61641-5."Under stress, people revert. They will skip writing tests. They will put off refactoring. They will avoid integrating. With your partner watching, though, chances are that even if you feel like blowing off one of these practices, your partner won't."
- Williams, Laurie; Kessler, Robert (2003). Pair Programming Illuminated. Addison-Wesley. p. 24. ISBN 0-201-74576-3."With any software development process there is a constant struggle to get the software engineers to follow the prescribed process. A benefit of pair programming is improved adherence to procedures and standards."
- Williams, Laurie; Kessler, Robert (2003). Pair Programming Illuminated. Addison-Wesley. p. 24. ISBN 0-201-74576-3."Others see us already working with someone else, and they leave us alone. The net effect is that we have bigger blocks of uninterrupted time, which is good for our mental state and our progress. It also reduces task-switching, which for some people generates a huge overhead."
- Williams, Laurie; Kessler, Robert (2003). Pair Programming Illuminated. Addison-Wesley. p. 21. ISBN 0-201-74576-3. "In our recent Web survey, we asked, 'What have you found beneficial about pair programming?' The single most common response was, 'It's a lot more fun!'"
- 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.
- 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.
- Aranda, Jorge (2007-03-12). "Pair programming evaluated". Retrieved February 7, 2008.
- Lui, Kim Man; Keith C. C. Chan, John Teofil Nosek (March/April 2008). "The Effect of Pairs in Program Design Tasks". IEEE Transactions on Software Engineering 32 (2): 197–211. doi:10.1109/TSE.2007.70755.
- 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.
- Stephens, Matt; Doug Rosenberg. "Will Pair Programming Really Improve Your Project?". Retrieved 28 May 2011.
- 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.
- Lui, Kim Man (2010). "Pair Programming: Issues and Challenges" (PDF). Agile Software Development: Current Research and Future Directions.: 143–163. Retrieved 2013-10-30.
- Flor, Nick (2006). Globally distributed software development and pair programming. Communication of the ACM, 49, 57-58.
- 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.
- Agile Ajax: Pair Programming with VNC
- Pair Programming - The Ultimate Setup and the other options we tried. - Jonathan Cogley's Blog
- 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.