Rather than slavishly pair program all the time, we use pair programming selectively on our team. I think it works best in the following circumstances:


Ramping up brand new team members on a project (instead of letting them wade through documentation or code on their own).
Having junior and senior people work together (helps to show some of the skills and tricks of the more experienced developers, plus it allows the old dogs to learn new tricks sometimes).
When someone is trying to track down a defect, it often helps to pair with a fresh set of eyes.


When to use pair program and why?

When to avoid pair programming? Why?

Research compiled by Laurie Williams indicates that pair programming works best on industrial teams when


Pairs work on specification, design, and complex programming tasks - experiments indicate that no quality improvement is shown when working on simple tasks in a pair but there may be speed improvements.  Also note that pair "programming" often includes activities other than writing code.
Each individual in a pairing has about the same level of expertise - while pair programming is great for training, pairs are most engaged when they are about on the same level.
Roles rotate regularly - rotating regularly helps keep the current copilot engaged as individuals tend to contribute most when they drive or sense they are about to drive.
Pairs rotate regularly - teams have expressed comfort in knowing about different parts of the system they are building.  Pair rotation helps with knowledge transfer which reduces certain risks in the project.  In an academic setting pairs are often assigned, however industry they are generally self-assigned often during stand-ups.  In both cases, the pair is most effective when both individuals are willing participants who see value in the pairing activity.


In my personal experience I've found that my XP team spends about 60% of our development time pair programming on average.  The remainder of the time is spent doing individual development.  It is not uncommon to pair up to create an initial design, work alone on the design for a few hours, then come back together to finish tricky or difficult parts of the code.

I've also found that pair programming is most effective in approximately 1.5 to 2.5 hour blocks.  Anything much less tends to require too much overhead to setup while much more and the pairs tend to get cranky and tired.  Cranky and tired means you're not communicating well and might be letting defects slip into the system.
