Pair programming trade-offs

I attended the local cloud computing group meeting tonight. The presentation was on pair programming, one of the elements of agile development. The concepts were familiar to me, yet I took home a few thoughts:

Pair programming requires you to work with another person: You have to put aside your ego and listen to the other person. This idea goes back to at least the 1970s; Gerald Weinberg wrote about egoless programming in his "The Psychology of Computer Programming".

Pair programming affects productivity: Managers take note, because this affects the project schedule. With pair programming, time for development increases. It takes longer to implement the same features, compared to solo programming. (But not twice as long, oddly. The initial increase is sixty percent, but drops to twenty percent as people become comfortable with working in pairs.)

While the development time increases, so does the quality. The increased quality means fewer defects and therefore less time and effort for testing. Thus, pair programming shifts the effort from testing to development, with an overall reduction in effort (and time). The project manager must weigh the benefits and costs of this trade-off.