Follow Jack on twitter @JacopoTarantino for other related topics.
Lots of companies embrace pair programming as a way to increase programmer productivity (loosely defined here as delivering “value” which can have many forms, but is generally interpreted as writing more code per day) but is it really that great? I’ve wondered why we should pair program and when is the right time to embrace it as a strategy.
Pair programming, as I know it, came into popular culture as a facet of XP (extreme programming), a development framework that enforces practices that generally improve software quality and responsiveness. The idea is a new incarnation of the old adage “two minds are better than one”. Either way, the idea is right: two people have different histories, cultures, and experiences, and for those reasons they think about things in different ways. When two people work on a problem together they almost always come out with a better solution that if one worked on it alone. So how does this relate to programming?
The Good
Pair programming does reduce bugs
The primary driver for pair programming is to increase quality and decrease bugs. When done well, it does that spectacularly. One study found that pairing reduced bugs in production by 15%!
Pairing does increase code quality
Many of the benefits of pair programming are not actually technical; they’re social. When working with a peer, it’s normal to feel encouraged to do your best, ensuring your coding is clean and avoiding any technical debt that you’ll “fix later”. When pairing, we tend to do things just a little bit cleaner, make algorithms just a little bit easier to read, name variables a little bit more sensibly. We actually write our unit tests to 100% coverage! With two sets of eyes, the quality is always higher.
The Gotchas
Pair programming does not eliminate bugs.
As much as we’d love for pairing to just eliminate all bugs, it’s just not the reality. Bugs still happen. There are generally a lot fewer of them, but perfect code would require perfect programmers.
Pair programming does not fix bad product direction.
Good projects need very strong product direction. And to be clear, the responsibility for this direction is on everyone, not just “product people”. It begins with asking questions and making informed decisions about work to be done. Then the team needs to thoroughly discuss the work, breaking it down as much as possible to understand the full scope. If this isn’t done properly, deadlines are missed, everyone is stressed, work that should take minutes takes days… Pair programming can’t fix that. Nothing is more important than good product direction.
Pair programming costs a lot.
Like, a lot. One study found that pairing increases the cost of software by 100%. While that seems like a predictable number (1+1=2), it’s actually highly variable. If pairing is used effectively, I would say it strictly costs the amount of time put in, minus the value added. It could be a single-digit percentage. On the other hand, if pairing is done poorly, you’re paying about 300% more. That’s 100% for putting another salaried employee on the same project, 100% for that that employee not adding any value, and 100% for the opportunity cost of other work they could have been doing. Make sure you’re doing it for the right reasons and utilizing the right resources.
You have to do pair programming right for it to mean anything.
Pair programming is a tool meant to help make a difficult problem more digestible. Pair programming done correctly generally means one person is writing code and the other is directing the work. Directing in this case means providing feedback about best practices and constructive criticism. It also means researching those best practices when you don’t know them off the top of your head and taking the time to think deeply about possible edge cases and hangups relevant to the work at hand. Pairs should communicate thoroughly, share all relevant information about their work, and swap duties as often as possible. It’s taxing to think about problems in both a creative and technical way, so it’s better to distribute that work. That’s one big reason that pair programming is such an effective tool.
So when are we supposed to pair program?
Pair program when there is a *very* difficult problem at hand.
If you have a problem you cannot reasonably break a big problem down into smaller parts, that’s the kind of thing that should be attacked by multiple programmers. An 8-point story should generally never exist in your organization if you’re doing normal web work. Features can almost always be broken down into “front-end” and “back-end” stories. Whole-page mockups can be broken down into component parts. Design and QA phases can also be separated out into their own stories. But a really tough problem is just a really tough problem. Trying to add a new feature to a language is a really tough problem. Trying to figure out how to reduce the latency on database calls is a really tough problem. These are examples of problems that require both creative and technical thinking.
Pair program when 2 programmers are at completely different skill levels.
Pair programming is a remarkably good way to teach junior programmers. Getting to participate live while a more senior programmer talks about how and why they’re doing something is invaluable experience. So is writing code while a more senior programmer coerces better practices on the fly. In my time as a programmer, pairing with somebody significantly more senior than me has been some of the most difficult and most rewarding work I’ve ever done.
Pair program when 2 programmers have completely different skill sets.
If you choose not to break down a story into easily divisible parts, having 2 programmers with complementary skill sets can be very rewarding for both the programmers and the codebase. Pairing programmers who generally only work front-end or back-end can get an end-to-end feature out the door, or you might have a Postgres expert pairing with a Scala expert to make your database calls more efficient. When these 2 people work together live, they absorb a lot of knowledge about each other’s domain and ensure there’s no aspect of the project that’s neglected.
Pair program when you’re both new to a language or framework.
Sometimes you wind up in a situation where nobody is an expert. Even if you’re working on a trivial feature and just wandered into a very difficult problem (see above). This is an excellent opportunity! You end up with two programmers working through a difficult problem and contributing their individual skills to build a better product, helping each other learn, and with a redundancy in the skill growth of your programmers. This is important because the skills in your organization should never be concentrated in one person. Having programmers pair on new languages and/or frameworks ensures that there are a minimum of two people who can work on this in the future.
This post is another one by InRhythm’s own Jack Tarantino. For the full post, check out the original “when to pair program” on his website.
