Pair Programming Is Too Expensive

"We can't afford to pay two people to work on the same thing!" This is pure
money risk. Fortunately, it just ain't so.
This objection assumes that pair programming costs more than having people
program alone. Research has shown that "development time" does increase with XP
by about 15% (not 100% like a knee-jerk reaction might suggest). However, thesecosts are offset by higher design quality, reduced defects, reduced staffing risk,
increased technical skill, and improved team communication and morale.1 It is
economically more feasible to program in pairs.
Our personal experience tells us that the economic feasibility goes up as the
group size increases, assuming the other practices of XP are in place. This is
because the overhead of communication is proportionately much lower while the
quality of communication goes up (see the section "I heard it through the pairvine".
Even if it were more costly in terms of development time, it is still better to
program in pairs. The toughest part of programming is design, and that happens at
the keyboard, not in an architecture picture. Would you trust your design to one
person? If you don't pair, you are. You are building extreme dependence on your
"stars". Even worse, you are counting on your less experienced developers to
implement that design without significant checks on their work.
Without pair programming, you are opening the door for more bugs to make it
into later testing and into the released product. You are meeting all the prerequisites
to attain hard to maintain code. Is it better to have someone else verifying the code is
up to par as it is written or to depend on unchecked code? Suppose you actually
produced the documentation of this code at some point. Why is it too expensive to
have a second set of eyes on the code but not too expensive to have a developer take
the time produce unverified documentation of the more than likely subpar code?
How can you be sure that the documentation (even for some moment in time)
accurately represents what is in the code? If it is generated from the code to keep it
up to date, it doesn't tell you anything the code can't tell you, so why do it? Ask the
manager to be as scrutinizing about existing practices as he is about pair
programming. If you can get him to be honest, he will quickly discover that
traditional practices increases his project risk to the point that he cannot afford not to
pair.
You might not pair all the time. There are tasks (such as exploration or
debugging) that might make sense to do alone sometimes. But pairing should be the
norm. Anything else is too risky.