Getting started with pair programming

As it turns out, one of the least used practices of agile development is also one of the most powerful.

Up into the start of last year, I only worked sporadically with pair programming. Last year, I was lucky enough to be part of a team that used pair programming all the time. Since I’ve experienced real pair programming, I never want to give it up.

Pair programming offers benefits to many stakeholders:

  • As a developer, you will have more fun at work. You will get to know your colleagues better and experience flow practically the whole day. You will be tired by the end of the day, but you will also feel like you’ve accomplished good work.
  • The team will have a higher quality code base that everyone is comfortable with.
  • As an architect or team lead, you will have a good way to contribute even if you only have a little time before a meeting. You will also have a better chance to influence the rest of the team, instead of just issuing edicts that nobody follows.
  • As the project manager, you will have a more flexible team. If someone gets sick, goes on vacation or moves to another project, there won’t be a big problem.
  • As the customer, you will get better quality code faster.

With these benefits in mind, why doesn’t everybody pair program? Well, it is unfamiliar, a little scary, and exhausting when you start out. Most developers are not used to having other watch them code. Or to focus on the task at hand the whole day.

Here are some techniques I’ve seen have effect for teams transitioning to pair programming:

  • Code dojos: Everyone on the team gets together and programs a sample program or a spike together. Two people sit at the keyboard, while the rest watch on a projector. Rotate pairs frequently. This lets everyone get comfortable with coding as a social activity.
  • Pair programming should be the norm, but allow for exceptions. If people only pair program occasionally, they end up not pair programming at all. If people are forced to pair program when they just need some time by themselves to think, they will not be happy pair programming.
  • The pair programming star: Write the names of the team members in a circle. Every time two people pair program, draw a line between their names. Keep the pair programming star in a visible location.
  • Facilities: The furniture can make it harder to get started pair programming. Consider using two mice, two keyboards and perhaps two monitors per PC to make it easier. Or use VNC for desktop sharing.
  • Give it time: Pair programming is exhausting when you first start doing it. It will take a while before people are comfortable with the new pace. But once they switch, they will never want to go back.

Resources

For more inspiration, see these presentations from the Smidig 2009 conference (in Norwegian):

Comments:

Johannes Brodwall - Jan 14, 2010

Great question.

It is very dangerous to fall into the “trap” of not pair programming a particular task and then ending up not pair programming at all.

I find that most tasks I intuitively feel are wrong for pair programming really are. Personally, I expect that talking about a codebase as I explore it with a partner is much more fun and effective than doing it alone. But I might be wrong.

However, there is one reason not to pair program for a while that you should always allow: If you’re just too tired. :-)

[thomanil] - Jan 14, 2010

Nice post.

One question: do you find pair programming to be equally effective for all types of programming work? Ie. if you are able, would you reach for this tool all the time, for all tasks?

For example: sometimes I need to wrap my head around a big/new problem. This can entail jumping around the codebase, reading code, writing some explorative tests. Having a concurrent conversation with someone else can be really irritating and distracting at that point.

To put it a different way: I feel that some tasks benefit from collaboration/conversation, while other tasks are easier to get done with some peace and quiet (ref the debate on enclosed offices vs open offices, see PeopleWare by DeMarco etc) What’s your opinion on this?

Would love to pair program consistently over a longer period to make up my mind about this! :)