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 1 Benefits 2 Drawbacks 3 Scientific studies 4 Remote pair programming 5 See also 6 References 7 External links

[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

• Extreme programming
• Software Development Rhythms
• Wiki:PairProgramming
• Wiki:PairProgrammingPattern
• Wiki:PairRotationFrequency

[edit] References

[edit] External links

• Pair programming page at C2
• wikiHow: How to Pair Program
• Virtual Pair programming page at C2
• Williams, Laurie & Robert Kessler (2000), "All I Really Need to Know about Pair Programming I Learned in Kindergarten", Communications of the ACM 43 (5): 108–114, <http://citeseer.ist.psu.edu/williams00all.html>
• Agility counts, The Economist, Sep 20th 2001
• Article Will Pair Programming Really Improve Your Project? from Methods & Tools
• Pair Programming Productivity: Novice-novice vs. Expert-expert International Journal of Human Computer Studies Vol 64 (2006) 915-925
• Williams, L.; R.R. Kessler & W. Cunningham et al. (2000), "Strengthening the case for pair programming", Software, IEEE 17 (4): 19-25, DOI 10.1109/52.854064
• Arisholm, E.; Gallis, H.; Dyba, T. & Sjoberg, D.I.K. (2007), “Evaluating Pair Programming with Respect to System Complexity and Programmer Expertise”, Software Engineering, IEEE Transactions on 33 (2): 65-86, DOI 10.1109/TSE.2007.17 
• "pair programming" article index at Agile Alliance
• Lui, K.M.; Chan, K.C.C. & Nosek, J. (2008), “The Effect of Pairs in Program Design Tasks”, Software Engineering, IEEE Transactions on 34 (1) 
• Gobby, a multiplatform collaborative real-time editor with syntax highlighting for almost all languages
• Sangam, a pair programming plugin for Eclipse. Not updated since 2004.
• collab.NetBeans, the NetBeans collaboration project, allow distributed pair programming and code review.
• MoonEdit, a multiplatform collaborative real-time editor.
• SubEthaEdit a collaborative real-time editor for Mac
• Coda a SubEthaEngine-based collaborative real-time web editor for Mac
• UNA A real-time collaborative development environment, which allows remote pair programming.
• XPairtise, a distributed pair programming plug-in for Eclipse
• No one should work alone. Ever. A practical real-life take on pair programming.