PairProgramming, while not a new concept, is the source of some lively discussion. Please carry that on here.
For some qualitative support of the effectiveness of PairProgramming, see AcmOnCollaborativeProgramming.
PairProgramming yields the following benefits, roughly ordered from largest benefit to smallest:
Also, LaurieWilliams famously demonstrated improved quality for slightly more effort in her The Collaborative Software Process paper (available at http://collaboration.csc.ncsu.edu/laurie/Papers/dissertation.pdf) [Is this the right one?]. A result that nobody else has been able to recreate since. Laurie is also the author of a book on the benefits of Pair Programming......
I've tried PairProgramming only a few times, but those times were far more productive than any I've had by myself. It's great fun, it's more efficient, and it helps me keep the right time and code perspective. I only wish I could do more of it. Since I'm the only programmer where I work, I've had to resort to VirtualPairProgramming -- ShaeErisson
I had a client blather about how they were using XP as their development environment -- yeah, except for all the regular practises like writing tests before code, pair programming, short iterations, et al. Oh, well. One time I had an opportunity to work with another guy who had some "free" time (well, not free to the client, of course). I can't recall exactly what we were working on, but it was complicated enough that I wanted somebody else to backstop me on the design and implementation. In a single two hour session we knocked out a subsystem that would have taken me all day had I been working alone. At the end of it we looked at the results and neither he nor I could tell whose ideas and code were whose. Yeow! It worked pretty durn well that time. -- MartySchrader
Moved from PairProgramming: Regarding the benefits of PairProgramming, when i have the opportunity to promote XP practices (usually to mgmt during a presentation on process), i have been presenting the following supporting argument (among others), linked to some research:
1. Projects with high quality (attention to quality) have lower schedule pressure:
3. Regarding inspection and quality and schedule, inspection is a powerful tool:
-- CraigLarman
JoeDavison kindly added to and incited me to improve my model for DayCare to pick up additional factors. One is the CornFieldEffect, which says experts work better together than separately (just as corn gives greater yield when grown in proximity rather than isolation). Another two are the mentoring effects - better design and faster training, which apply when the people have different amounts of expertise. To me, the additional factors for DayCare provide a bit of a model to explain some of the added productivity in PairProgramming. -- AlistairCockburn
One of the other benefits of PairProgramming is its effect on code/design/produced object quality. It is amazing how many obvious but unnoticed defects become noticed by another person watching over your shoulder. In addition, the intimacy of this method makes it possible for defects to be exposed in a non-judgemental manner.
The first time I heard of this paradigm being used in a formal, organizational sense was in DeMarco & Lister's PeopleWare, where they mention it as a benefit and give the example of Whitesmith's (an old compiler company founded by PjPlauger) as a place where it was practiced. [I believe this is actually in ConstantineOnPeopleware; see http://www.cs.utah.edu/~lwilliam/proposal.htm for a reference. --PaulChisholm] Anything earlier? -- FrankAdrian [hounds are coupled together for hunting (and a pack of N hounds will be referred to as "N/2 couple"), so if you're willing to accept non-humans, the practice is at least centuries, and probably millennia, old. A fox or hare that's backtracked and crossed a stream is probably just as annoying as a bug that doesn't manifest until the stack's unwound and execution is deep in some other module...]
Noel Morris and I used this approach in 1965, writing programs for CTSS. It is mentioned in my note, "The Evolution of My Thinking," http://www.best.com/~thvv/evolution.html. [404] -- TomVanVleck
One of the rules of the ChryslerComprehensiveCompensation team is that all production code be written with a partner. As a testimonial, in the last six months before launching, the only code that caused problems was code written solo. -- KentBeck
{RonJeffries writes this about part of ExtremeSoftware as practiced at Chrysler ... http://www.xprogramming.com/Practices/PracPairs.html)
Copied this from comp.software.extreme-programming:
As I see it, there are a few sides to the Mentoring benefit at the top of this page. These may be worth spelling out in the hope that they can be used to persuade traditional project managers to trial pair programming:
See: PairProgramming