Pair programming

From Wikipedia, the free encyclopedia

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.

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

Some benefits of pair programming:

  • 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: 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 significantly reduces 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]
  • Fewer workstations required: Since two people use one workstation, one fewer workstation is required.

[edit] Drawbacks

  • Developer egos: Experienced developers may find it tedious to tutor a less experienced developer in a paired environment.
  • Developer intimidation: A less experienced developer may feel intimidated pairing with a more experienced developer which may result in less participation.
  • Developer work preference: Some engineers prefer to work alone, and may find the paired environment cumbersome.
  • Tutoring cost: Experienced developers working alone may be capable of producing code that is clean and accurate at the outset, and the additional theoretical gain from pairing might not be worth the cost of an additional developer. This is especially true when producing more trivial parts of the system.[citation needed]
  • Potential conflict: Differences in coding style may result in conflict, and personality conflicts can result in one or both developers feeling awkward or uncomfortable.
  • Chat sessions: Sometimes employees might talk together too much, straying excessively into off-topic subjects, such as major news events, personal problems, etc.
  • Annoying personal habits: Sometimes people can find each other much more annoying when working up close than at separate workstations.

[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 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]

A recent study by Lui, Chan and Nosek published in IEEE Trans Software Engineering shows that pair programming outperforms for design tasks.[15]

[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.[16][17].

[edit] See also

[edit] References

  1. ^ Williams, Laurie (2001). "Integrating Pair Programming into a Software Development Process". 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."
  2. ^ a b c d e f Cockburn, Alistair & Williams, Laurie (2000), “The Costs and Benefits of Pair Programming”, 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, 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, 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, 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, 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, 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, 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, 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, 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, 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" (September 20, 2001). The Economist. .
  13. ^ According to "Int J. of Human Computer Studies Vol (64) 2006
  14. ^ Pair programming evaluated « Catenary
  15. ^ http://csdl2.computer.org/persagen/DLAbsToc.jsp?resourcePath=/dl/trans/ts/&toc=comp/trans/ts/5555/01/e1toc.xml&DOI=10.1109/TSE.2007.70755)
  16. ^ Agile Ajax: Pair Programming with VNC
  17. ^ Pair Programming - The Ultimate Setup and the other options we tried. - Jonathan Cogley's Blog

[edit] External links