Pair Programming - Does it work?

tl;dr - It depends.

Pair programming is defined as the act of two programmers working at one workstation on one task at a time. One programmer enters the code (the driver), leaving the other programmer free to audit the code in real time as it’s being written (the observer). The idea behind it is simple: two heads are better than one. When someone else is watching you, your proclivity for stupid typos and silly programmatic errors is significantly less (forgetting semicolons for example).

From a programmer’s perspective, pair programming is like having two brains. One is focusing on the logical factors and the actual act of typing the code in, and the other has a wider, more strategic view of how the code will pan out in the long run.

From a managers perspective however, you’re saving money on desks and computers (not chairs) but you’re spending twice as much money on man hours. The real question is: do the benefits outweigh the disadvantages? If you’re coming up on a deadline for a client fast, and you need results quickly, then maybe. If you’re in no particular rush, save yourself the money and split your resources.

One of the often touted advantages of this buddy system is that the pair not only keep each other focused, but honest at the same time - noone wants to be the slacker. Because there’s only one workstation, there’s no time to check emails, tweet your favourite celebrities or read your Facebook wall. The task is always at hand.

So the moral of the story is, if you have an unlimited budget but no time, give Pair Programming a whirl. If you have no budget but plenty of time, then it isn’t really a good fit.

If, like most real life situations, you have neither money or time, then make sure you really know your programmers before pairing them up. It has the potential to blow up in your face. On the other hand, it might just be worth the risk.