The Myth of Pair Programming Productivity

Is pair programming more effective than individual programming for improving code quality and productivity?

Pair programming can be fun. It can be a great way to transfer knowledge. It can be good for teaching.

And in narrow situations it can be good for productivity, especially when you need multiple experts to consult on the same task.

So as a tool, it's useful to keep around.

But given the productivity of a reasonably experienced, skilled, and competent programmer, the concept that two of them together will always be more than twice as productive than the two would be separately seems impossible.

In order for two developers to produce code at more than twice the velocity, that implies that they're spending more than half of their time making mistakes and backtracking or being “stuck.” In my experience, a good developer can maybe, at best, get a 10-20% boost from real time feedback, and that's being generous. I've been in hour long pairing sessions where the person I'm pairing with made a single comment that saved me at most thirty seconds.

And as to quality, a similar logic applies: If I need to have someone constantly looking over my shoulder in order to produce quality code, then I must not be a very good (or experienced) programmer.

But there do exist companies that practice constant pair programming. There are some, or so I've been told, that practice mob programming, where there may be five or six people in front of a big screen. All the time.

While pair programming can be fun, and even extremely productive under the right conditions, mob programming sounds like either a complete waste of time or the ultimate in “back seat driving” for code.

So why do companies do something that really shouldn't be effective?

Well, there are studies that show that lower skill developers can be more productive when pairing. So that makes hiring easier, and they don't need to pay their developers as much that way. The same studies show that individual higher skill developers still are faster, and create higher quality code, than the pair of lower skill developers. But the lower skill developers do better than when working separately.

Two lower skill developers tend to cost more than one higher skill developer, especially when you factor in their lower overall velocity, so this doesn't fully explain why some companies would use constant pairing, though.

But those companies that most often utilize pairing also bill by the programmer hour. So the fact that the developers, who are each being billed at a high hourly rate, take longer to produce a result could be considered a feature.

So no, I don't think pair programming is more effective than individual programming except for when you are trying to set up a situation where you're using mediocre developers in an attempt to bill more hours to a client. Or alternatively, when you are unable to attract and hire high skill developers for whatever reason.