June 3, 2011

Why you must embrace pairing

Pair programming increases software quality without impacting time to deliver. It can seem counter intuitive, but two (2) people working at a single computer will add as much functionality as two working separately except that it will be much higher in quality. With increased quality comes big savings later in the project.

The best way to pair program is to just sit side by side in front of the monitor. Slide the key board and mouse back and forth. The person that is doing the typing is known as the driver while the person that is guiding is known as the navigator. It is often suggested for the two partners to switch roles at least every half-hour.

The driver thinks tactically about the methods being created and actively implements the program.

The navigator continuously observes the work of the driver to identify tactical (syntactic, spelling, etc.) defects and also thinks strategically about the direction of the work.

* It takes time to get used to pair programming so don’t worry if it feels awkward at first.


Pair programming yields the following benefits, roughly ordered from largest benefit to smallest:

  • Increased disciplinePairing partners are more likely to “do the right thing” and are less likely to take long breaks.
  • Better codePairing partners are less likely to go down rat holes and tend to come up with higher quality designs.
  • Resilient flow. Pairing leads to a different kind of flow than programming alone, but it does lead to flow. Pairing flow happens more quickly: one programmer asks the other, “What were we working on?” Pairing flow is also more resilient to interruptions: one programmer deals with the interruption while the other keeps working.
  • Improved moralePair programming, done well, is much more enjoyable than programming alone, done well. (On the other hand, pair programming done poorly is much less enjoyable than programming alone done poorly.)
  • Collective code ownership. When everyone on a project is pair programming, and pairs rotate frequently, everybody gains a working knowledge of the entire code base.
  • Mentoring. Everyone, even junior programmers, has knowledge that others don’t. Pair programming is a painless way of spreading that knowledge.
  • Team cohesion. People get to know each other more quickly when pair programming. Pair programming may encourage team jelling.
  • Fewer interruptions. People are more reluctant to interrupt a pair than they are to interrupt someone working alone.
  • One less workstation required. Since two people use one workstation, one less workstation is required, and therefore the extra workstation can be used for other purposes.

Studies have shown that after training for the “people skills” involved, two programmers are more than twice as productive as one for a given task.

Some good practices to keep in mind:

  • Switch roles (navigator/driver) every 30 – 40 minutes or so.
  • Work for 90 to 120 minute burst of concentrated effort, then break for 15 – 20 minutes.
  • During your work burst, no email, phone calls, IMing. Try to keep it as focused as possible. Use your breaks for email and the like.
  • Support your partner, be encouraging. Style flex.

Rest & Relaxation

Pair programming is a lot of work. Sharing is hard, as anybody who has observed a preschool classroom will note. Working side by side taxes even the most peaceful programmers. You will need to remember to take breaks before tempers flare.

Pair programming is more intense than solitary programming, because somebody is always driving. It’s like running in a relay race where you hand off the baton and then hop on a bike to keep up with your partner. One reason XP recommends you work only 40 hours a week is that pair programming is hard. To be an effective partner, you need to be fresh and rested. The 40 hour work week reminds us that most of XP’s practices were devised to address the human side of software development.