Pair programming

related topics
{math, number, function}
{system, computer, user}
{rate, high, increase}
{work, book, publish}
{service, military, aircraft}
{theory, work, human}
{math, energy, light}
{album, band, music}

Pair programming is an agile software development technique in which two programmers work together at one work station. One types in code while the other reviews each line of code as it is typed in. The person typing is called the driver. The person reviewing the code is called the observer (or navigator[1]). 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

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.[2]. Studies have found reduction in defect rates of 15% to 50%, varying depending on programmer experience and task complexity.[3][4] Pairs typically consider more design alternatives than programmers working solo, and arrive at simpler, more-maintainable designs, as well as catch design defects early.[5] 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.[2][6]

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

Full article ▸

related documents
Bit error ratio
Random access
Metcalfe's law
Escape character
GNUstep
ABC (programming language)
Baud
Wikipedia:ASCII art conversion tool
Common Language Infrastructure
Extensible Stylesheet Language
Netwide Assembler
Name server
Sanity testing
Filter (Unix)
Wavelet compression
Dining cryptographers protocol
Data stream
Zombie process
Wikipedia:Federal Standard 1037C terms/telecommunications encryption terms
Java remote method invocation
Visual Instruction Set
Alternating bit protocol
Longitudinal redundancy check
Advogato
Pseudorandom noise
Poem code
Scanline rendering
Automatic data processing
Common Language Runtime
Entropy encoding