Rails Test Prescriptions Blog

Keeping Your Application Healthy Since 2008

Pair Programming, or Two of a Kind

Repeating yourself is clearly an occupational hazard of blogging. I’ve been trying to put together a post about pair programming for a while. Somewhat randomly, I found myself wandering through my blog archives at Pathfinder, and I came across this little essay, which was the last thing I wrote at Pathfinder before, shall we say, Events Transpired, so I probably blocked it a bit. I definitely blocked the responses that were on the Pathfinder blog the following week, because, well, Events Were Transpiring.

Anyway, at the time, I was not paring particularly consistently at Pathfinder (small team sizes being the main culprit), but I have spent most of the last eight months at a client site that does aspire to constant pairing. I find that my basic opinion — pairing is valuable to a point, but you can over-pair to the team’s detriment — hasn’t changed, but it has sharpened a little. A few observations:

First off, a real problem I have when writing about pair programming is that a significant percentage of the people I’ve been pairing with recently are likely to read this. I don’t mean anything by it — it isn’t you it’s me. I apologize in advance, and all that.

  • No programming technique is always appropriate, and that goes for pair programming, too. Some tasks, especially the rote, boring yak-shaving ones, don’t need a pair, and the team should have leeway to make that decision.
  • Have a plan with your pair. The Pomodoro 25 minutes on/ 5 minutes off thing is effective, but you need to agree to it (or some variation) when you start. However, a project with a long build time or test suite run time really kills any kind of Pomodoro-like schedule.
  • Pair programming is part of the agile bet — in my experience it’s almost always a short term time loss with the hope of better performance over the long haul. I know there are studies that say that two programmers pairing are faster that two programmers working alone. All I can say is that isn’t consistently my subjective experience. It is common to work in a pair that is short-term faster than I would be on my own, but I don’t always feel like the pair is faster than both programmers would be on their own separately. Again, that’s in the short term.
  • The bet is that the investment will pay off over time in lower defect rates and better knowledge transfer. And I do think that’s reasonable, but it’s by no means assured.
  • I think the best long-term goal of pairing is to keep knowledge from being siloed within the team. Anytime you are forced to say something like, “that’s a search problem, Fred has to work on it”, that becomes a potential bottleneck for your team. So rotating pairs such that everybody gets to do everything is an important part of what makes pairing work.
  • That said, people external to the team love knowing that if it’s a search problem, then Fred needs to work on it, so they
    hate it when pairs rotate, because they don’t know who to talk to about issues having to do with a particular feature. If you are pair rotating frequently, people outside the team need to have some way of discovering who is the current contact on a story or set of stories.
  • You’ll often hear the highly irritating argument that pair programming works because it’s less likely that one programmer will slack if there’s a pair. Maybe. My experience, both direct and through observation, is that the effect works in reverse, too, which is to say that the slacking pair member can drag down a working member. (I’m totally not going to say whether I’m the slacking pair or the working pair.)
  • There’s a strong personality component here — some people really love pair programing, some people genuinely don’t. (As for me, I’m mostly neutral but there’s definitely a point where I just want to put the headphones on and grind away on a problem…)
  • Logistics are a major pain in pairing. You pay for mis-alignment of time. One person gets in a half-hour earlier. They eat lunch at different times. One person gets pulled into a meeting (a particular problem if you are pairing senior and junior members), hell, one person goes to the bathroom more. Every disconnect gets felt when a team is pairing. Mandating specific hours and eliminating work at home is emphatically not keeping with the spirit of agile as I understand it, so what’s the solution?
  • Pairing, by definition, leads to a loud work environment — pairs need to talk. Some people will definitely find this to be a problem, and I think it can work against concentrating on a problem.
  • Ultimately, I think it’s a problem if pairing is the only way that team members are allowed to work, both for logistical reasons, and also for loud work environment type environmental reasons. Which leads to the radical mush-mouth position of “pair when it’s appropriate, don’t when it’s not”, which is a really annoying conclusion to come to at the end of a blog post like this.
Advertisements

5 responses to “Pair Programming, or Two of a Kind

  1. Frederick Polgardy July 12, 2010 at 7:25 am

    Thanks Noel. I’m 100% with you. I feel like there are certain tasks that scream for it, and many which really really don’t. Some devs say they just can’t do quality work anymore without pairing. That has not been my experience. The no-slacking argument is actually a strong one – I’ll confess, I’m the slacker – but it’s when I’m most in the zone that I actually most DON’T want to pair. I’ve only very rarely been in the zone with a pair, and it takes a really particular kind of individual and task for that to be the case. (Last time was around 2002 I believe.)

  2. Scott Parker July 12, 2010 at 9:13 am

    Great writeup Noel. Definitely agree with you on the “Have a plan” part, particularly in regards to the pomodoro technique. I find that having sticking to that plan helps alleviate the “logistics” issues you raise, but also helps me last longer and stay energized when pairing.

    Plus it goes a long ways towards defeating any slacker tendencies I may have that day.

  3. Dan Cummings July 12, 2010 at 11:58 am

    I also think Pairing benefits assume all developers are equal, in some cases I believe pairing can actually inhibit the more experienced developer and hides the opportunity for training and skill development of more junior developers. That being said I am for pairing but not until the team has demonstrated mature agile programing discipline.

  4. Frederick Polgardy July 12, 2010 at 3:15 pm

    Dan: I think most pairing proponents actually argue that pairing a junior and senior developer together is a Good Thing because it facilitates mentorship.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: