When 1 + 1 != 2

The common belief about pair programming is that you achieve the productivity of 1.5 developers on their own. The problem with this measurement is that the productivity of each developer is unique to that developer. Also, it assumes that the developer is productive at a steady pace for 8 hours a day 5 days a week.

I believe that in rather common situations pair programming can be much more or less productive. And, while 1.5 may be the mean, it's more often much more or less.

Since I joined ThoughtWorks I've noticed increases in my productivity. This is for several reasons, including:

1. Pairing doesn't allow slack time. In the past I often completed tasks ahead of schedule and ended up with extra time. Usually, I filled this time with browsing, emailing, etc. However, pairing forces me to focus and move on to the next task.
2. Pairing gives you 2 points of view. The continuous code review provides confidence. There is no better feeling than programming with confidence. Test driven development gives you some confidence; however, it only validates what you test. Pair programming goes above and validates the design from 2 points of view while development is being done. Additionally, 2 points of view limits wasted time. Have you ever had the feeling that what you were doing was wrong and you were going to have to throw away the code? Unfortunately, when I'm not pairing I usually finish, and then look at what I can improve. Then, often, I have to explain the code to someone else to get their point of view. And, in the end I throw most of the code away. However, when I pair, the other developer is following my train of thought and we can stop, visualize the end result, and discuss better options.

Just these two examples make me significantly more productive. However, in the past I've been very unsuccessful with pair programming. I can very vividly remember what went wrong.

1. Workstation set up. Have you ever tried to drive on someone else's computer when they used a natural keyboard and you are used to a laptop keyboard? You adapt, but it's annoying. Obviously, productivity will suffer some.
2. Motivation. My first pairing partner and I had something in common, lack of motivation. We couldn't get our schedules to match, and we ended up spending much of our time explaining what we had done while the other person was away. Then, when we did pair, we weren't focused and spent much of the time day dreaming. Why pay attention, someone else was doing the work. We were both slackers, but pairing couldn't remedy our slacking if we weren't motivated.
3. Speak the language. Nothing is more frustrating than looking to someone for design advice and they are stuck on something syntax related.

Issue 1 is minor, but combine it with 2 or 3 and productivity becomes horribly low. Even 2 or 3 alone can destroy the flow of development.

Do you know anyone indifferent about pairing? I don't, it's a love or hate relationship. I think this is largely because of the productivity that is achieved. If you have a successful experience you see how great it is and love it. Obviously, it can also be painful and very unproductive, thus the hate emotion. But, if you don't love pairing, I'd have to ask if you actually love programming.