Thursday, May 10, 2012

Pair Programming: How To Do It Right

Pair programming is an XP practice of putting two people in front of a computer, and having them program together. If you haven't seen it work before, it sounds wasteful. It is wasteful if you have one person writing code while the other passively watches, but there are some practices that make it a lot more valuable. When done right, I consider "paring" to be vastly superior to solo programming.

The way I have done pair programming goes hand-in-hand with test driven development. Here are the techniques I have used.

Ping-Pong Pairing

This is a beginner technique. It can get you in the groove for a day of pairing, and it's also useful as an introductory technique to pair programming.

Here is how it works:
  1. Developer A: write a failing test
  2. Developer B: make the test pass
  3. Refactor together
  4. Developer B: write a failing test
  5. Developer A: make the test pass
  6. Refactor together
  7. Rinse and repeat
The idea is to make a game out of it. Write the simplest possible piece of code to make the test pass, and do so as quickly as you can.

Navigator / Driver

Notice that this isn't "Observer / Driver", as I have sometimes seen it described. I don't like "Observer", because it implies a passive role. At it's best, the person who is not writing code should feel like they are working harder than the person on the keyboard.

This is an intermediate-to-advanced strategy, and the way that pair programming works in a high-functioning team. The roles are:

  • Thinks strategy: "What do we need to test?"
  • Keeps the overall objective of the story in mind.
  • Keeps track of potential refactorings along the way.
  • Does NOT tell the Driver what to code.

  • Thinks tactically: "How do I write this test?"
  • Focused on the next small step.
  • Keeps up a dialogue with the Navigator, describing what he/she is doing.

The key is to switch roles periodically. You don't want to do it too often, or you risk getting out of a good rhythm. You don't want to do it too seldom, because it's too easy for the Navigator to become disengaged.
Good times to switch are when:
  • There is a change of concept.
  • "I need a change."
  • A timer beeps (this isn't a bad way of starting with this technique, but not best for long-term).
Post a Comment