What make pair programming doom

When start talking about pair programming, it's so obvious that there must be two people working together. wow it sounds such a wasteful to spend on work that can be done with only one man work. I would say 'yes' and 'no'. it's all about how you implement it. Kent Beck has a good explanation and guide line about XP. I'm here not to repeat him, but just to give some feed back of what I have read and sharing some experience that my team has implemented for this last 5 months.

What made our team success

1. Our work survives and goes smoothly width rhythm of switching keyboard, writing test, make the test pass and refactor the code. one person become a driver start writing a test, then other person become an observer and thinking ahead of making the test pass. after the driver finished hist test, he pass the keyboard to other person to make the test pass and he becomes the observer. the next person just has to make the test pass, no matter how the ugly the code is. Once the wrote the code that makes the test passes, Then he passes the keyboard to other to make the code clean.
2. Break the big task into smaller task that can be done within a day if possible and keep the rhythm to complete those tasks.
3. Survive with rules defined by team. Rules is one of the most important thing to make pair programming effectively executed. eg. the team member must update the code every morning, every time he wants to added new feature or event before start fixing bugs. the member must not leave code uncommitted over night. That looks simple, but it needs times, effort and practice to be part of your work.
   

I think i won't go to much into detail, Kent Beck is still the best person that you can refer to regarding all aspect of pair programming.