Noel Rappin Writes Here

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.