As with most Agile claims, I'd like to see that proven first. Even then I might wonder whether it's the right thing for me, but at least we could have some numbers how this works out in general.

If you've got a high fault rate, two people working things out might improve things enough to be worth the while. Especially in a case were uncaught bugs are really band and/or your daily coding is an exercise in tedious input checking, c.f. some web sites and conventional GUIs.

And even then I'd say that the occasional meeting plus a decent code review process would probably be as effective, without the hit in performance. Never mind the sheer annoyance a lot of people would feel having to "couple" all the time.

>If you measure productivity more like "features delivered per month" (and negatively adjust for bugs that make it to production) I contend that pair programming will probably yield more favorable numbers.

There's no credible evidence to support that claim.

On the other hand, pair programming generates a lot of churn (discussions about details between the pair programmers, the outcome of which bears little consequence on the solution of the problem) and that alone is guaranteed to negate whatever gain you could expect from pair programming.

In my experience, asynchronous code reviews work a lot better.

"There's no credible evidence to support that claim."

My experience supports it. Can you point to credible evidence to support your claim?

And my experience contradicts it. So what? The burden of proof is on the people claiming that it's more productive to do pair programming all the time, rather than just doing code reviews, collaborating when you need it, and otherwise not cutting your team in half. eXtreme claims require extreme proof.