In my experience, pair programming is more productive than dividing the work between two
programmers and then integrating the results. Pair programming is often a sticking point for folks
wanting to adopt XP. All I can say is that you should get good at it, then try an iteration where you
pair for all production code and another where you program everything solo. Then you can make
your own decision.
Even if you weren't more productive, you would still want to pair, because the resulting code
quality is so much higher. While one partner is busy typing, the other partner is thinking at a more
strategic level. Where is this line of development going? Will it run into a dead end? Is there a
better overall strategy? Is there an opportunity to refactor?
Another powerful feature of pair programming is that some of the practices wouldn't work without
it. Under stress, people revert. They will skip writing tests. They will put off refactoring. They will
avoid integrating. With your partner watching, though, chances are that even if you feel like
blowing off one of these practices, your partner won't. This is not to say that pairs don't ever make
process mistakes. They certainly do, or you wouldn't need the coach. But the chances of ignoring
your commitment to the rest of the team is much smaller in pairs than it is when you are working
alone.

//testing
Testing is perhaps the most frustrating area when you are shifting existing code to XP. The code
written before you have tests is scary. You never know quite where you stand. Will this change be
safe? You're not sure.
As soon as you start writing the tests, the picture changes. You have confidence in the new code.
You don't mind making changes. In fact, it's kind of fun.
Shifting between old code and new code is like night and day. You will find yourself avoiding the
old code. You have to resist this tendency. The only way to gain control in this situation is to bring
all the code forward. Otherwise ugly things will grow in the dark. You will have risks of unknown
magnitude.
pag 102