From the Site Guidelines:

Please don't do things to make titles stand out, like using uppercase or exclamation points, or adding a parenthetical remark saying how great an article is. It's implicit in submitting something that you think it's important.

http://ycombinator.com/newsguidelines.html

EDIT: That said, good read.

Mea culpa. No harm intended, just had never read the guidelines.

+1 - A fact-based discussion of the reasons I am of one those programmers that love pair programming.

Regarding the Expert Programmer Theory: I find it rare that my pair and I get 'stuck'. Rather, discussion at the early stages of implementing a plan head off any decisions that will end up with us being stuck.

That said, the times I usually find my pair and I getting stuck is in the naming of concepts within the domain. At this time, polling those developers around us helps out enormously.

Regarding 'change blindness': This is where I find some of the most value from pairing. I find that I get (and give) a lot of value in the catching of minor logic errors, changed method or variable names, and simple typos.

I'm certainly no opponent of pair programming, but its proponents often seem not to address the 0th order argument against it: the parallel/series problem. To complete tasks A and B, Alice and Bob can finish them in parallel if they work alone, but can finish them only in series if they work together. This means that, for equal-sized tasks, solo programming is a priori twice as productive as pair programming. I'm perfectly willing to believe that the benefits of pairing can overcome this factor (and more), but that's a strong claim and requires strong evidence.

In my experience (24 years in a large company doing a lot of large projects), the coupling of different pieces of the program is severely underestimated. The result is that The Plan lays out the schedule with Alice and Bob working in parallel, but in reality they end up requiring a lot of interaction before the project is done.

Typically in a large project, Alice and Bob work independently but make different assumptions and have to rework a significant amount of their code when they finally get together to integrate their two parts.

In my experience, large teams can shrink calendar schedule time by brute forcing the dependency failures. The trade-off to achieve schedule compression is substantial inefficiencies and often a loss of quality and maintainability. I am convinced that a lot of schedule slippage in large projects is due to incorrect assumptions with respect to the independence of the pieces. While it is possible to compress the schedule this way, all schedule compression that exceeds the true parallelism in the project requires exponentially increasing effort to overcome the inefficiencies due to the coupling.

This is behind Brook's Law http://en.wikipedia.org/wiki/Brookss_law "2. Communication overheads increase as the number of people increases." Communication overhead is the indication of coupling of the pieces. If Alice and Bob's pieces were truly independent, they would not need to communicate and Brook's Law would not apply.

The physical analogy to the effort required to shrink calendar time is the "hull speed" of boats. http://en.wikipedia.org/wiki/Hull_speed and http://en.wikipedia.org/wiki/Wave_making_resistance. While it is possible to "escape your bow and stern waves" (i.e plane), it takes an exponential amount of power to do so. (The first wikipedia page links to another nice explanation: http://www.antrimdesign.com/articles/hullspeed.html.)

In my experience, working as a pair produces bug-free code at least twice as fast as working singly.

The person not typing spots bugs a lot better than the person at the keyboard, and having someone to bounce designs off of means you don't head down the wrong path with them.

I find a flaw in your reasoning sir, you are making a rather large assumption that in pair programming both the participants must have same set of skills. Its rather the opposite I think, they must actually have mutually exclusive skill sets. Like one should have a problem solving mind(navigator) and the other should have a solution implementing mind (driver). Thus if they both work parallel they would actually take more time in solving the same problem rather than if they work in series. For an example if I want to make bio informatics program I would rather be a driver and code and have a navigator who has skills in the other parts of the program.

A former co-worker of mine went to work at Pivotal Labs, where full time pairing is the mandate. After just a month, he quit "the best company he'd ever worked for," and wrote up a lengthy blog post on why pairing didn't work for him: http://mwilden.blogspot.com/2009/11/why-i-dont-like-pair-pro...

Reading this article reminds me of a small company in Ann Arbor, MI called Menlo Innovations (http://www.menloinnovations.com/), which pair programs exclusively. Their founder has spoken at our university a number of times about the effectiveness their methods. In my eyes this article quantifies to some extent what he's said.

It's really nice to see a formal review of something I've learnt organically. Good read and really interesting reflections on the practice.

The most spot-on description of the benefits I've ever read. Balanced and scientific treatment of the subject.

I don't do it formally, but it often happens that I'm sitting at a co-worker's machine and asking to have the mouse or keyboard. We do spot each others' typos, but I drive her nuts with my preference for the caps lock key.

Very solid write up.