Pair programming
Encyclopedia
Pair programming is an agile software development
Agile software development
Agile software development is a group of software development methodologies based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams...

 technique in which two programmers work together at one workstation. One, the driver, types in code while the other, the observer (or navigator), reviews
Code review
Code review is systematic examination of computer source code. It is intended to find and fix mistakes overlooked in the initial development phase, improving both the overall quality of software and the developers' skills...

 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.

Costs and benefits

Some studies have found that programmers working in pairs 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 solo, 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.

However, a 2007 meta-analysis
Meta-analysis
In statistics, a meta-analysis combines the results of several studies that address a set of related research hypotheses. In its simplest form, this is normally by identification of a common measure of effect size, for which a weighted average might be the output of a meta-analyses. Here the...

 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
Publication bias
Publication bias is the tendency of researchers, editors, and pharmaceutical companies to handle the reporting of experimental results that are positive differently from results that are negative or inconclusive, leading to bias in the overall published literature...

 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."

Even though coding is often completed faster than when one programmer works alone, total programmer time (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.

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.

Additional benefits reported include increased morale and greater confidence in the correctness of the code.

Scientific studies

According to The Economist
The Economist
The Economist is an English-language weekly news and international affairs publication owned by The Economist Newspaper Ltd. and edited in offices in the City of Westminster, London, England. Continuous publication began under founder James Wilson in September 1843...

,
"Laurie Williams of the University of Utah
University of Utah
The University of Utah, also known as the U or the U of U, is a public, coeducational research university in Salt Lake City, Utah, United States. The university was established in 1850 as the University of Deseret by the General Assembly of the provisional State of Deseret, making it Utah's oldest...

 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."


The Williams et al. 2000 study showed an improvement in correctness of around 15% and a 20%–40% decrease in time, but between a 15% and 60% increase in effort—that is, total programmer-hours. 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.

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.

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, reduced duration for simpler tasks comes with noticeably lower quality – the meta-analysis "suggests that pair programming is not uniformly beneficial or effective".

Non-Performing Indications

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
Integrated development environment
An integrated development environment is a software application that provides comprehensive facilities to computer programmers for software development...

 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 by a screen sharing software
(such as VNC or RealVNC
RealVNC
RealVNC is a company that provides remote access software. The software consists of a server and client application for the Virtual Network Computing protocol to control another computer's screen remotely.-History:...


or the multi-display mode (-x) of the text-based GNU screen
GNU Screen
GNU Screen is a software application that can be used to multiplex several virtual consoles, allowing a user to access multiple separate terminal sessions inside a single terminal window or remote terminal session...

)
or by specialized distributed editor tools (such as Gobby
Gobby
Gobby is a free software collaborative real-time editor available on Windows and Unix-like platforms. It was initially released in June 2005 by the 0x539 dev group....

, Saros
Saros (software)
Saros is an Eclipse plug-in for distributed collaborative text editing that can support arbitrarily many participants at once.It can be used for a variety of purposes ranging from simple remote code review, over Remote pair programming, through to variants of Side-by-side programming with more than...

 or XPairtise).

Ping pong pair programming

In ping pong pair programming, the observer writes a failing unit test, the driver modifies the code to pass the test. At this point, they swap roles and the original driver (as observer) writes a failing test. The original observer (now driver) modifies the code to get the new test to pass, and so on. This loop continues as long as either member of the pair is able to write failing unit tests for the other to implement. In general, this approach may take more time than the estimated plan.

See also

  • Extreme programming
    Extreme Programming
    Extreme programming is a software development methodology which is intended to improve software quality and responsiveness to changing customer requirements...

  • Wiki:PairProgramming
  • Wiki:PairProgrammingPattern
  • Wiki:PairRotationFrequency

External links


Programs and plug-ins to support remote pair programming

  • Eclipse Communication Framework Includes Cola, an Eclipse
    Eclipse (software)
    Eclipse is a multi-language software development environment comprising an integrated development environment and an extensible plug-in system...

     plug-in
  • Saros An Eclipse
    Eclipse (software)
    Eclipse is a multi-language software development environment comprising an integrated development environment and an extensible plug-in system...

     plug-in
  • XPairtise An Eclipse
    Eclipse (software)
    Eclipse is a multi-language software development environment comprising an integrated development environment and an extensible plug-in system...

     plug-in
  • wave-vs.net Plug-in for Visual Studio
The source of this article is wikipedia, the free encyclopedia.  The text of this article is licensed under the GFDL.
 
x
OK