A while back I had an email discussion with an old colleague who was trying to introduce some XP principles into his team’s process. Part of the discussion focused on pair programming. Since I’ve had discussions like this several times, I decided to convert it into a blog post so I can point here instead of repeating myself. Efficiency!

I’ve been on a couple teams that said they do pair programming “sometimes” and on another that says they do it “always”. In my experience, pairing “sometimes” really means “every once in a while when someone is having a problem”. It’s more like “occasional pair debugging” in those cases. The team that did it always really did do it always. Not pairing was the exception for that team. And let me tell you: I got a lot of work done every day working on that team. When you pair all the time, it’s very hard to get distracted. At the end of the day I was mentally and physically exhausted!

The team also rotated pairs. I think this is important. You do want to mix it up so juniors get mixed with seniors, people with lots of context/knowledge on a subject get paired with people with little, and you want to avoid cliques and silos. Doing it this way brings up the level of the entire team. Junior people progress to senior level skill and everyone has shared knowledge of the project as a whole instead of each person knowing their small piece.

It is sometimes a tough sell. It’s easy to see it as cutting your productivity in half. It might be easier to sell a couple “pairing days” per week to test the waters. See how the team likes it and if they do they can help sell it. Or hey, maybe once or twice a week just slowly becomes 3 or 4 days a week and no one notices.

The selling points of pairing:

• Programmers are more likely to stay on task. Especially if you rotate the pairs: you WANT there to be a bit of uncomfortableness to avoid people buddying up and goofing off. Instead, they’re more likely to avoid doing things like checking email, facebook, whatever and spend more time getting down to business. In my experience, in the long run, you get more done in the same amount of time because of this.

• If someone is sick, on vacation, etc. you don’t run the risk of loosing all the context for a particular piece of the system. You no longer hear “oh, Joe was the one working on that. I don’t know anything about it” because with rotation, everyone is working on everything.

• The skillset and coding style of the team begins to coalesce. That means code reviews take much less time and you are less likely to hear “Joe wrote this code, it’s going to take me a while to figure out what he was doing…”.

• The skill level of everyone improves. With rotation, people learn from each other. The backend pros get better at frontend work by working with the frontend pros and vice versa (just one example).

• Programmers spend less time over-thinking a problem. When you are working with someone else, you want to keep the momentum going and are more likely to move on once you have an adequate solution instead of getting bogged down trying to come up with the perfect solution.

All this can add up to more business value for a team where pairing is a good fit. And don’t think remote workers means pairing isn’t a good fit (usually it’s more about time zones and work schedules), but that’s a subject for another post.