Buddy Programming

Sometimes, the practices of Extreme Programming can be a bit too extreme when first introducing them to a team. This is especially true with pair programming.

Of all the practices that I teach software developers, I get the most resistance from pair programming, Both developers and their managers are skeptical about pair programming, although each has different concerns.

Managers tell me they can’t afford to cut their developers’ productivity in half — but that actually doesn’t happen. Productivity increases for teams that do pair programming well for a number of reasons, but most fundamentally because when people are working together, they stay focused on a task more consistently than when they’re working on their own. This has several side effects, including fewer bugs, higher quality code, and better work habits.

The resistance I get from developers is different. Their main concern is often compatibility between partners, but it usually turns out that we can be most productive with people who are different from us rather than the same as us. It’s the differences between us that make for a good pair. Our differences can often complement each other. When everybody understands the ground rules and the purpose of pairing, it can grow into a very positive experience.

I know teams who pair on everything because they find so much value in it most of the time. Of the hundreds of teams I’ve introduced pair programming to, many of them continue to use the practices. Developers love pair programming when they’re introduced to it correctly.

The trick to getting a team to adapt pair programming is often just getting them to try it. When I encounter a team that’s reluctant to try pairing, sometimes I’ll suggest another technique that I call buddy programming.

Buddy programming is not pair programming. With buddy programming you work on your own, by yourself, for most of the day, the way traditional knowledge workers typically work. However, at the end of the day, you get together with your buddy and walk through the code you each wrote since the last time you were together.

You’re checking in with another person, either at the end of the day or at the beginning of the next day for maybe an hour or so and reviewing each other’s work including decisions, designs, code, questions, etc. I find that this approach can often be a gateway for developers to adopt pair programming. They find it so productive working with their buddy that they do more and more of it throughout the day until it eventually goes from code reviews to code creation.

Some teams prefer to stay with buddy programming and use it as a way of enforcing code reviews among the team. However, I have seen other teams soften to the notion of pairing and move from buddy programming to pair programming as the way they work most of the time.