And More Problems
Chapter 7 of PPI (titled "Problems, Problems") discusses several problems with pair programming. We briefly discuss some of these problems here. Although the authors of PPI do offer some practical advice to overcome or help prevent these problems, the proposed solutions either result in high maintenance or rely idealistically on the programmers being constantly aware of all the problems (with advice such as "Just proceed a bit more cautiously"). One problem is that of rushing. Because pairs rotate often, they might rush to finish a task before it’s time to separate. The advice given in Chapter 7 of PPI is as follows:
"If a task must roll over to another pairing session, the task must roll over to another pairing session! Slow down, and do it right together." 
The coach would need to be particularly vigilant to spot this problem recurring, because pairs rotate so often. If the problem happens a lot, it may be because the tasks are too big (another direct consequence—evidence of the circle of snakes unraveling. To counter this, the team may need to spend more time planning or designing, or change its process for estimating stories or tasks). Another problem, which we suspect would particularly manifest in teams that publicly laud themselves as "the best team on the face of the Earth," (such as the original XP team that worked on the infamous C3 project) is that of overconfidence:
"There may be a feeling that a pair can do no wrong. If you’re working together, you might convince yourself that whatever you do together must be right. Remain cautious and careful!" 
The problem of overconfidence would need to be watched for carefully by the coach, who should be aware of this type of problem. She would then need to be able to watch out for the telltale signs and be prepared to act on them when she catches pairs reassuring each other into writing bad code. "Well, I suppose it will do for now—we can refactor it later!" is the typical start of a slippery slope. Another problem is that it’s human nature for people to want to be in control, at least of their immediate surroundings:
"New folks should specifically be paired with mentoring types, lest they feel unwelcome or frustrated in the hands of a partner who wants to make only personal progress. This mentor must also give up control and allow the less skilled team member to drive most of the time. When the mentor is directing most of the activity, it’s better for the trainee to be typing and not just listening. The student might not be assertive enough to ask for the keyboard." 
This is, of course, an idealistic approach. As we discover in Rich Camden’s "Voice of eXPerience" account , being in control of the keyboard is the preferred option for most people. Rich wasn’t offered the keyboard once in 5 months (that’s not to say that he didn’t get to type, but no one actually offered to relinquish control). If the other person doesn’t speak up, he’s not going to be offered the keyboard. As the previous quote suggests, this is particularly a problem with inexperienced programmers being allocated an experienced partner. Everybody likes to be the driver, to be in control.
Watch Out, There’s a Snake Under the Desk!
The problems we just described must all be watched for and quickly fixed before they lead to other problems. This is a lot of problems associated with one XP practice, all waiting to slip and catch the unwary coach, who must be especially vigilant.
Pair programming by itself can be a beneficial practice, but in an XP project its problems are much more acute because (as we discuss in Chapter 3 of Extreme Programming Refactored) so much else in XP relies so heavily on its correct and consistent execution throughout the project.
 Matt Stephens and Doug Rosenberg, "Extreme Programming Refactored: The Case Against XP", Berkeley, CA: Apress, 2003
 Laurie Williams and Robert Kessler, "Pair Programming Illuminated", New York, NY: Addison-Wesley, 2002
Originally published in the Winter 2003 issue of Methods & Tools