As with the other pairing combinations, pairs rotate so frequently that in a team of mixed abilities, the novice-novice pairing could happen quite often. Therefore, novice-novice pairing isn’t something that can easily be controlled: It just happens, almost by accident, several times a week. The coach must be fully aware of the fact that two novices are currently pairing at any time, and the coach must be available to guide them and correct their mistakes. In practice, to combat the proverbial blind leading the blind, there’s a risk that the coach may become fully occupied with mentoring one particular pair anytime two novices pair up.
Carrying Your Pair
Similar but less extreme problems occur with expert-average pairing. PPI describes three situations where the authors feel that expert-average pairing is a problem. The first is that the average programmer truly is average (i.e., the average programmer is likely to stay that way and will never really progress). The second is when the average programmer doesn’t interact enough with the expert. The third is when the average programmer doesn’t seem to "get it" and keeps asking the same question over and over:
"This can leave the expert frustrated and can reduce the ability of the pair to complete the task." 
And the Winner Is . . .
Aside from the longer-term learning benefits, it seems that the most beneficial form of pairing is with two programmers of roughly the same ability. It’s more likely that the pair will be on the same wavelength and will spend less time disagreeing over things that probably don’t matter that much. Unfortunately, when you consider that 50% of all programmers are below average, it becomes obvious that mixed-ability pairing is likely to be the norm. This highlights the problem that teams of mixed abilities are almost unavoidable. Pair programming makes the issue unavoidable by forcing these people to code together on the same program.
In a non–pair-programming project, the problem is handled effectively through other more natural practices, such as team leading, code and design reviews, occasional (voluntary) pair programming, mentoring, design documents, and so on. With almost all of the problems described in this article, it’s up to the coach to catch and deal with them as promptly as possible. This places a lot of responsibility on the coach (almost as much as the on-site customer!)
Design Documents Reduce Reliance on Pair Programming
Design documents provide a record of design decisions. This makes them particularly helpful for novice programmers to explore the thinking behind the design, as described by the more experienced senior programmers. If the team is becoming lost in a sea of changed minds and refactorings, the design document often helps to remind the team members of why they originally decided to do something in a particular way. There’s usually a pretty good reason.
We discuss the role of documentation in software projects (and how it can lessen the need for pair programming) in Extreme Programming Refactored Chapter 7 .