[Research compiled by Laurie Williams][1] 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.

  [1]: http://collaboration.csc.ncsu.edu/laurie/Papers/ESE%20WilliamsPairProgramming_V2.pdf