Andy Kelk

Pair programming: Making the case for its survival

When we started transitioning to Agile, we were lucky to have support from senior management as well as coaching from external consultants. Part of the deal was that we dived fully into XP including TDD, BDD and pair programming. One of the team rules (that’s literally written on the wall) is that all production code must be done in a pair. Before we moved to Agile we had a very strict peer review policy which mandated that all code committed to source control must be reviewed by another developer. Pairing provides that peer review as well as a whole lot more.

Now that we’re getting more comfortable with Agile and are becoming less reliant on our coaches, there are rumblings (quiet and far off ones, admittedly) around pair programming and I’m starting to feel that I have to justify the practice. I would have hoped by now that the benefits of pairing would have been obvious. It seems I may still have a bit of sell to do. I think I can build a convincing case in favour of pair programming.

  1. You get the product quicker. There have been studies that show pairs complete deliver code quicker than programmers working solo. For example, one study shows that pairs did the same work 40% more quickly [source]. Double the people does not mean double the “man hours”; typically the number of “man” hours spent in total is around 60% more in a pair than with one person working alone.
  2. You get a better product. Overall, teams where pair programming is used produce code with fewer defects than those who work alone. It’s very easy when pairing for one member of the pair to spot simple defects creeping into the code. Ping-pong pairing (where one pair writes the test, the other makes it pass) can also have a big impact as two people will tend to come up with more edge cases than a solo programmer.
  3. You get knowledge sharing. One of the big problems in any organisation can be the creation of “islands of knowledge”. When pairing (and particularly when regularly rotating pairs), everyone gets to touch every part of the system. This means that you don’t end up with one person who is the only one who understands a certain part of the code.
  4. You get skills transfer. Pair programming is a great way for novices to learn from experts. However, beware of assuming that once everyone’s been “trained” that pair programming should be stopped. We also use pairing to cross-skill the team so that, for example, developers learn UI skills.
  5. You don’t waste time. No-one in the team is going to admit it, but if they’re left on their own they waste an awful lot of time. It’s not necessarily malicious, they just reach a roadblock and attention wanders; they read a blog, read some email, check their share portfolio and lose productive time. Not only does having a pair provide peer pressure to keep on working, it also helps prevent you getting to those roadblocks because you have two brains on the one task.
  6. You have happier developers. The developers enjoy pairing – they feel more energised about the tasks they’re doing, they are supported in getting the work done and they are working together as a team. Pair programming can be a leap into the unknown for those who haven’t done it but after taking that leap, the outcome is almost always positive.

Personally I think that number 6 alone is worth doing pairing for, but I know that I’m going to have to work hard to keep pairing as a core part of our development practices.

Leave a Reply

Your email address will not be published. Required fields are marked *