Blog An exploration of the art and
craft of software development

Pair Programming Thoughts

Posted by Marty Haught on Monday, June 01, 2009

Last week @bryanl requested some opinions on pair programming and I’m finally getting around to posting my thoughts. I’ve been pairing on development teams since 2004 though in the last 6 months I’ve seen very little pairing due to being on a super small teams. This post will focus on the observations I’ve made about pairing during that time. Most of these points will be about healthy pair programming. Like with most practices, if you do it wrong it can do more harm than good.

Here’s a list of benefits I commonly see to pairing:

  • Better library, gem or plugin knowledge is present and thus more potential for avoid ‘reinventing the wheel’.
  • Really cool designs are realized through the give and take of the pair which results more often than I would expect.
  • Simple mistakes or poor decision making can be reduced without extra time being lost. Think of someone working solo for most of the day only to find out that there was a better way the next morning at the stand-up.
  • Coding standards have a better chance of being followed over solo development.
  • Knowledge transfer is always happening thus it doesn’t take much work to get to where each dev on the team knows 90% of the code.
  • Instant mentoring is a given, especially if you bring on new team members. Any developer skill can be improved whether it’s new tricks for mastering your editor/dev tools, code techniques, troubleshooting short-cuts, etc.
  • Improved team chemistry as everyone on the team works together.
  • Less code ownership as people will not be the only one working on some part of the system.
  • Less distractions so you can be in ‘the zone’ more of the time. Minimizes the productivity killers (twitter, email, surfing)

Looking over the list you see the usual suspects in terms of improving code quality. I have heard some complaints that once you get to a certain level pairing isn’t of benefit anymore. I have found this not to be true especially when I’m pairing with someone equal or greater than me in skill. Where I see pairing exceeding expectations is in team improvement and reducing distractions. This can be really true when you bring on new team members, especially those with less experience. Pairing is the fastest way to make this new member productive and comfortable in your team. For really experienced members, pairing is a chance to gain confidence in your fellow co-workers as well as improve their skills.

So I mentioned healthy pair programming so what do I think that looks like. First, you should be alternating pairs frequently, such as once every day or two. Definitely avoid the ‘pair for a week’ syndrome. Second, I’d have multiple pairs work on the same part of the system, if not story. Avoid the same guy is always in a pair on the story that he originally started. This way you might get 4-6 developers familar with that code instead of just one or two. It really reduces code possessiveness. Make sure you’re alternating driver (the person typing the code) frequently. Ping ponging is an excellent technique to try. Another good technique is to have the person with the design in his head to talk and the other drive. The larger the dev team the more important pairing is. If you’re a shop of 2-3 then pairing may not happen as much. Once you’re over 4 developers I think you should have at least 2 pairs going at all times.

There are certainly some gotchas to pairing so here are some things to watch out for. Pairing is really intense. You have to be careful to have breaks and let there be some breathing room for non programming tasks. Watch out for extremely uneven pairs. You don’t want to always stick the uber-experienced rockstar architect with the newest junior member of the team. The senior will feel he’s just a trainer and the junior will not feel he’s doing anything of value. It’s okay to have this pairing some, just try to avoid it happening too often. Pairing is not an easy thing for most programmers so you need to be sensitive to how you introduce this practice. Personality conflicts can wrecked a pair, as well as a team. I think that any team member should be able to pair with another but you may need to ease into that. Make sure everyone gets to pair with someone more experienced or natural with this so that first time experiences can be positive ones. Another thing you can try is just pair for a few hours in the morning then let folks split off on their own for a while. That’s better than no pairing.

In conclusion, I feel that pair programming is a huge benefit to larger teams and would choose to spend my development budget on making it a regular practice over having team members flying solo most of the time. On smaller teams, I think it’s okay to not pair all the time. While I think you can pair just about anything in the development cycle it’s okay to have somethings not be paired such as css tweaking and experimental spiking. As with most things, context matters as well as your team size and chemistry.

blog comments powered by Disqus