Pair programming

From Wikipedia, the free encyclopedia

Jump to: navigation, search

Pair programming is a software development technique in which two programmers work together at one keyboard. One types in code while the other reviews each line of code as it's typed in. The person typing is called the driver. The person reviewing the code is called the observer[1] or navigator. The two programmers switch roles frequently (possibly every 30 minutes).

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.

Contents

[edit] Benefits

  • Design quality: Shorter programs, better designs, fewer bugs.[2] Program code must be readable to both partners, not just the driver, in order to be checked in. Pairs typically consider more design alternatives than programmers working solo, and arrive at simpler, more-maintainable designs, as well as catch design defects very early.[3]
  • Reduced cost of development: With bugs being a particularly expensive part of software development, especially if they're caught late in the development process, the large reduction in defect rate due to pair programming can significantly reduce software development costs.[2]
  • Learning and training: Knowledge passes easily between pair programmers: they share knowledge of the specifics of the system, and they pick up programming techniques from each other as they work.[2][4] New hires quickly pick up the practices of the team through pairing.[5]
  • Overcoming difficult problems: Pairs often find that seemingly "impossible" problems become easy or even quick, or at least possible, to solve when they work together.[2][6]
  • Improved morale: Programmers report greater joy[7] in their work and greater confidence that their work is correct.[2]
  • Decreased management risk: Since knowledge of the system is shared among programmers, there is less risk to management if one programmer leaves the team.[2]
  • Increased discipline and better time management: Programmers are less likely to skip writing unit tests, spend time web-surfing or on personal email,[8] or other violations of discipline, when they are working with a pair partner. The pair partner "keeps them honest".[9][10]
  • Resilient flow. Pairing leads to a different kind of flow than programming alone, but it does lead to flow.[citation needed] Pairing flow happens more quickly: one programmer asks the other, "What were we working on?" Pairing flow is also more resilient to interruptions: one programmer deals with the interruption while the other keeps working.
  • Fewer interruptions: People are more reluctant to interrupt a pair than they are to interrupt someone working alone.[11]

[edit] Drawbacks

  • Work preference: Some engineers prefer to work alone.
  • Intimidation: A less experienced or less confident developer may feel intimidated when pairing with a more experienced developer and participate less as a result.
  • Tutoring cost: Experienced developers may find it tedious to tutor a less experienced developer. Experienced developers working alone may be capable of producing code that is clean and accurate at the outset, and the benefits of pairing might not be worth the cost of an additional developer in some situations. This may apply more especially when producing more trivial parts of the system.
  • Egos and potential conflict: Personality conflicts can result in one or both developers feeling awkward or uncomfortable. Differences in coding style may result in conflict.
  • Annoying personal habits: People may become annoyed by other team members when pairing with them due to objections to certain of their habits.
  • Cost: There are varying opinions as to whether two developers can be as productive when working together as when working separately (see "Scientific Studies" below).

[edit] Scientific studies

Studies have shown that after training for the "people skills" involved, two programmers are more than twice as productive as one for a given task. According to The Economist,

"Laurie Williams of the University of Utah in Salt Lake City has shown that paired programmers are only 15% slower than two independent individual programmers, but produce 15% fewer bugs. (N.B.: The original study showed that 'error-free' code went from 70% to 85%; it may be more intuitive to call this a 50% decrease of errors, from 30% to 15%.) Since testing and debugging are often many times more costly than initial programming, this is an impressive result."[12]

The Williams et al. 2000 study showed an improvement in correctness of around 15% and 20 to 40% decrease in time, but between a 15 and 60% increase in effort. Williams et al. 2000 also cites an earlier study (Nosek 1998) which also had a 40% decrease in time for a 60% increase in effort.

A study (Lui 2006) presents a rigorous scientific experiment in which novice–novice pairs against novice solos experience significantly greater productivity gains than expert–expert pairs against expert solos.[13]

A larger recent study (Arisholm et al. 2007) had 48% increase in correctness for complex systems, but no significant difference in time, whilst simple systems had 20% decrease in time, but no significant difference in correctness. Overall there was no general reduction in time or increase in correctness, but an overall 84% increase in effort.[14][15]

Lui, Chan, and Nosek (2008) shows that pair programming outperforms for design tasks.[16]

[edit] Remote pair programming

Remote pair programming, also known as virtual pair programming or distributed pair programming, is the practice of pair programming where the two programmers comprising the pair are in different locations, working via a collaborative real-time editor, shared desktop, or a remote pair programming IDE plugin.

Remote pair programming might be useful to do pair programming with offshore teams or in open source projects with distributed contributors.

Some teams have tried VNC and RealVNC with each programmer using his own computer.[17][18]

Also of notice, IDEs like Eclipse and NetBeans offer their own solutions. For NetBeans there is the The NetBeans Collaboration Project[1] and for Eclipse, the Eclipse Communication Framework[2] comes with the Cola[3] plugin.

As for Cola, two videos are available.[19][20] A tech talk on the algorithmic internals of Cola, given at the Googleplex in June 2008, has been made available on Google's YouTube tech talks channel. A Cola demo is available in HD via vimeo.

[edit] Ping pong pair programming

Some agile teams use a different style of pair programming called "ping pong pair programming".[citation needed] In this pattern, the observer writes a failing unit test, the driver modifies the code to pass the unit test(s), the observer writes a new unit test, and so on. This loop continues as long as the observer is able to write failing unit tests.

[edit] See also

[edit] External links

 This article's external links may not follow Wikipedia's content policies or guidelines. Please improve this article by removing excessive or inappropriate external links.

[edit] References

  1. ^ Williams, Laurie (2001). "Integrating Pair Programming into a Software Development Process" (PDF). 14th Conference on Software Engineering Education and Training: abstract. http://ieeexplore.ieee.org/Xplore/login.jsp?url=/iel5/7294/19720/00913816.pdf. "One of the programmers (the driver) has control of the keyboard/mouse and actively implements the program. The other programmer (the back-seat driver) 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 e f 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), http://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF 
  3. ^ Williams, Laurie (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." 
  4. ^ Williams, Laurie (2003). Pair Programming Illuminated. Addison-Wesley. pp. 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."
  5. ^ Williams, Laurie (2003). Pair Programming Illuminated. Addison-Wesley. pp. 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."
  6. ^ Williams, Laurie (2003). Pair Programming Illuminated. Addison-Wesley. pp. 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."
  7. ^ Williams, Laurie (2003). Pair Programming Illuminated. Addison-Wesley. pp. 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!'"
  8. ^ Williams, Laurie (2003). Pair Programming Illuminated. Addison-Wesley. pp. 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).
  9. ^ Beck, Kent (2000). Extreme Programming Explained. Addison-Wesley. pp. 102. ISBN 201-61641-6. "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."
  10. ^ Williams, Laurie (2003). Pair Programming Illuminated. Addison-Wesley. pp. 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."
  11. ^ Williams, Laurie (2003). Pair Programming Illuminated. Addison-Wesley. pp. 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."
  12. ^ "Agility counts". The Economist. September 20, 2001. http://www.economist.com/displayStory.cfm?Story_ID=779429. .
  13. ^ Lui, Kim Man; Keith C. C. Chan (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. http://www.educ.msu.edu/DWongLibrary/CEP900/Library/Liu-ExpertNoviceProgramming.pdf. Retrieved on 2008-07-21. 
  14. ^ 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. http://simula.no/research/engineering/publications/Arisholm.2006.2/simula_pdf_file. Retrieved on 2008-07-21. 
  15. ^ Aranda, Jorge (2007-03-12). "Pair programming evaluated". http://catenary.wordpress.com/2007/03/12/pair-programming-evaluated/. Retrieved on February 7 2008. 
  16. ^ Lui, Kim Man; Keith C. C. Chan, John Teofil Nosek (March/April 2008). "The Effect of Pairs in Program Design Tasks" (PDF). IEEE Transactions on Software Engineering 32 (2): 197–211. doi:10.1109/TSE.2007.70755. http://www.cpe.virginia.edu/Quals%20Papers%20Aug%2008/SoftEng.pdf. Retrieved on 2008-07-21. 
  17. ^ Agile Ajax: Pair Programming with VNC
  18. ^ Pair Programming - The Ultimate Setup and the other options we tried. - Jonathan Cogley's Blog
  19. ^ "Wiring Hacker Synapses - tech talk on Cola internals". youtube.com. http://www.youtube.com/watch?v=GfeUCT-tRJQ. 
  20. ^ "Cola Real-Time Shared Editing Demo". vimeo.com. http://vimeo.com/1195398. 
Retrieved from "http://en.wikipedia.org/wiki/Pair_programming"
Personal tools