The Skeptical Methodologist

Software, Rants and Management

Pair Programming: Putting a Spy in Every Cube

Apparently, Facebook and Square can’t get enough pair programming. While the rest of us wait out the gloating of the all-grown-up start-up flavor-of-the-year rediscovering techniques known for decades by other firms and practitioners, someone in the counter-counter-culture has to speak up and say the obvious.

No, Pair Programming is not that effective.

First, let’s place Pair Programming in its philosophy and history. Its roots are in extreme programming, whereas the general approach is to take any ‘good’ thing and do it a lot more – take it to the ‘extreme’. So, in the case of unit testing, extreme programming advocates would move to test driven development. Pair programming is the end result of taking peer review to the extreme. “If some peer reviews are good”, so the thinking goes, “maybe we should peer review as much as we can? Maybe we should peer review constantly.

I bring that up to make the point that we should not be comparing Pair Programming with working alone. That’s not what it’s replacing. It’s replacing more traditional forms of peer review. So when you see the benefits of Pair Programming being extolled from on high, ask the question – Are they going on about the benefits of Pair Programming, or the benefits of peer review?

Most of the ‘bug-catching’ arguments in favor of Pair Programming are actually arguments in favor of peer review. Simply having someone else look over your work is not a new idea. Nor is it an ineffective one, as a few studies have pointed to peer review being the most effective means of preventing defects, per dollar spent.

So let’s only focus on the benefits of Pair Programming as compared with traditional means of peer review – in fact, let’s compare Pair Programming with its next closest relative in terms of peer review style. We’ll compare it to a process that advocates light weight peer reviews over small chunks of code done very often.  Moreover, I also want to make it clear I’m focusing on Pair Programming as your primary means of development. In most cases, what we might call Pair Programming is a very common event – one developer simply helps the other out on some sort of problem, or they both work on a particularly tricky part of a design together. This, for some reason, is just considered normal work, not Pair Programming. Pair Programming, it seems, is when management decrees you will work with another person even when you don’t need to.

The Benefits

The argument then becomes that Pair Programming finds defects slightly earlier than normal peer review would – instead of waiting a day or two, or perhaps hours, before you can submit your work for peer review, your pair would point out flaws and you two would fix them. The argument would continue by relying on the much repeated philosophy that a defect caught earlier is cheaper to fix. If you can catch it in a few minutes, isn’t that cheaper than catching it in a few hours?

That may be true, but it is nowhere near the cost differential as catching a defect now to a few months from now. After a few hours of work, I am still very much in the context of the original defect, so it does not take nearly as much ‘spin up’ time to effectively quash the defect.

Does Pair Programming in this way save time? Yes. But not nearly as much as implementing peer reviews do in the first place. This implies that Pair Programming may have a negative balance in a cost benefit analysis. The benefits are there, but they are small. How about the costs?

The Costs

The costs are both implicit and explicit. First, you are tying up two developers. Even in the most generous terms, I’ve heard pair programming might increase productivity by around 150% compared to a single developer. That means, on average, you’re down half a person.

And even those generous terms may be misleading. Let’s say I have two developers, one who’s not too keen on actually programming and is probably in the wrong field (i.e., 80%+ of the developer population), and a superstar. The dullard may code at around 50% productivity by whatever measure. When I compare him to a superstar programmer, that superstar programmer may code at around 150% productivity by the same measure. Seeing a superstar being about 3x more efficient than a dullard is not uncommon. Their arithmetical average productivity is 100% – the average developer.

Now I pair the two, and their joint productivity springs forward to 150%! They’re more productive than the average developer, so one assumes something in the method is working. But let’s casually stroll by their cube and see the magic in action. Lo and behold, the superstar is in the driver’s seat, doing mostly what she was doing before, and the dullard simply looks on and remarks about the occasional missing semi-colon. No one’s more efficient – we’ve simply improved our numbers by taking the keyboard away from the dullards.

Notice one extolled benefit I’m putting squarely in the implicit cost column – wasted time. Some might argue Pair Programming reduces time wastage, on the internetz for example, or using one’s smart phone. This, unfortunately, assumes time wasted is something to minimize. This, in turn, is unfortunately something newly Peter Principal’ed managers in their early 30’s naively believe.

Developers – the good ones – enjoy development. They love what they do. So when they aren’t doing it, one has to assume that they aren’t doing it for a good reason. In many cases, people need the downtime to think about things, or just relax a bit after a few hours in the zone. Pair programming enforces through a cultural mechanism constant work. Even if your devs enjoy it, they’re going to be suffering due to lack of down time.

Peopleware, which ought to be canonized in our field, makes this point very clear in comparing the standard cubicle to the office of old. Offices increased productivity by such a large margin they paid for themselves many times over. Offices, it is to be remembered, reduce interactions, they do not encourage them.


Given the large costs and relatively small benefits, why is Pair Programming so popular? Well, follow the money – or at least, follow who it’s popular with. Amongst the developer community, you’ll see advocates on both sides. Some really love it, others hate it. The consensus seems to say it’s a useful technique in some situations.

But among managers, especially uneducated, newly minted managers who really don’t seem to understand there’s a whole field and literature devoted to the subject of managing organizations, love Pair Programming. And what they really love isn’t the method itself – sure, they might chime in about reduced defect rates and other supposed benefits. But what they really love about it is how close it is to the ultimate tool of uneducated managers – the bull pen.

Constant supervision

For some crazy ass reason, there’s a huge school of thought amongst managers (again, usually the type that don’t actually read any of the prior art in management and make it up as they go) that the secret to good management is supervising everything. You can’t trust your employees further than you can throw them, so the lower we can make these cubical walls, the more I can overhear everything, and the more time I have to walk around and status the hell out of you, well… that’s bound to increase productivity right? The fundamental assumption of the uneducated manager is all increases in productivity come from reductions in laziness.

Pair Programming cuts down the amount of work a manager has to do to keep an eye on you, to make sure that you’re doing whatever it is programming is (it’s mostly typing, right?). Pair Programming puts a spy in every cubicle. It’s no wonder overall productivity suffers so much. Morale plummets.

If not now, then when?

Pair Programming as practiced as an edict doesn’t seem to justify itself. Its marginal increases over standard iterative peer review are miniscule compared to the costs to culture, morale and productivity. It’s generally put in place as a means to supervise, not as a means to innovate. That being said, there are many cases where Pair Programming, in a looser sense, is very effective.

Particularly Hard Problems

There are times when something is just going to be really tricky to pull off, and you need help. You need constant conversation, constant white boarding, and constant prototyping with someone who can play devil’s advocate. Luckily, for us, we already ‘pair program’ in these cases.

Mentoring and Training

One place where Pair Programming could be used more, though, is in mentoring and training. Pairing a junior dev with a more senior and experienced dev is an incredibly effective and efficient way to get the junior both up to speed on the code base, as well as the idioms and practices used around the shop. Generally this will be a more hierarchical pair – it is clear who the driver will be, and who’s mostly going to just sit back and learn for the first couple of days. This limits some of the social strife pairing might cause when there’s disagreement, limiting the usual downside.

Cross Functional Pairs

A pairing I’d find very effective but don’t hear talked about too often is pairing developers with people from outside of development. This would go a long ways to prevent stove piping, provide for a common culture, and increase the bandwidth between these roles. Pair a developer with a UI designer, or a developer with a tester, or a developer with a business analyst. All of these would allow each of these specialists to learn a lot more about the other’s work habits and keep information flowing between them. I’d encourage this sort of pairing as well as job rotation amongst these roles to completely keep stove piping at bay.

Pair at your own risk

Pairing has a potential upside. This can be emphasized in specific situations when the pair has a lot to learn from each other, or when two heads really are better than one. But it also has costs, costs that get much worse when pairing becomes the default rather than just another tool in the chest.

Like all of our techniques, we need to look at when Pairing is warranted. There’s no rationality in saying ‘never pair’ any more than there is in saying ‘always pair’. Pair when it makes sense, when it saves time, when it builds teams. Otherwise, don’t feel so guilty about putting up an away message and keeping your office door shut.


August 28, 2012 - Posted by | Uncategorized

No comments yet.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: