So pair programming is the bastard step child of agile, in many ‘pragmatic’ conversations pair programming is dismissed by the smart folks. Is that fair?
I must prefix this post with saying i have never developed product using pair programming, so this comes from du brain not from du experience.
So as they say in shampoo comercials here is the *coff* psuedo *coff* science part.
FIrst lets get right out there and say that pair programming hits code efficiency, just in terms of laying down code – lets call that cost X. Now we have that out the way lets park it, (we shall return).
So are there any advantages? Now that we have parked the cost this bit is pretty easy.
o 2 people looking at code ARE going to have less defects, isnt that obvious (you are going to see that argument a lot as I think a lot of what makes pair programming is obvious).
o If you implement peer review then it must be more efficient to do that at the source, auto – review whats not to love!
o A slightly more complex thought – I would assert that there are two development mind sets the micro architecture and the macro. Using the micro-mind you are winding out loops, you are thinking about API and so forth. Using the macro mind you are considering the large scale impact of a change. Maybe its me, but I frequently development some code and am very proud but then have to burn it when I try to integrate it into the rest of the code base because I have missed the point (macro architecture). How is is not obvious that 2 mind sets is not best solved with two minds.
o .. OK bored now .. I am sure that if you disregard the cost you could think of lots of other advantages.
So lets return to the cost, given we have established the value Y is substantial (not saying its large just that its substantial). So can we get a view on the size of X.
Lets consider a different view of pair programming. 2 programmers and 2 computers, but you have a baton that must be past between the developers – you can only type when you hold the baton. What sort of efficiency would you (as a developer) would you lose under such an arrangement? I don’t think I would lose all that much, clearly I would lose some but *meh* not so much. Is this view of pair programming so different to the conventional view? I would assert its not – the limiting factor for pair programming is the keyboard – the keyboard is the baton. Your loss (2 programmers focusing on the same code base) is only there to realize the advantages above.
Summary: The only way that X is large is when the keyboard is a limiting factor in coding, I don’t know about you folks but my brain is a far bigger road block 🙂 therefore adding 2 brains to a keyboard actually make more effective use of a keyboard. I am not saying that X is zero, I am trying to show that X is modest, its a small number, it is in fact lower than the advantages – therefore its net positive!
BRING ON PAIR PROGRAMMING!
Scott's Home Online 
Certainly when I’ve been involved in pair programming the most productive combinations have been the use of a “big picture” thinker and a detail oriented thinker… the resulting code is both well formed and devoid of small scale defects.
Swapping over at the keyboard has natural points; strictly swapping over every N minutes isn’t useful — generally the participants know when to changeover.
It’s also quite liberating being able to hand off — just as you hit the end of your internal buffer and start to flag a little, the other of the pair has thought through the next section and is ready to go. There’s an energy there. You can see more work being done. It **FEELS** productive which is well over halfway to being productive.
Interestingly, many writing pairs work similarly; alternating at the same keyboard, one typing detail, one thinking structure.
~Katie