A Pair of Kings Beats A Single Ace: Pair Programming

This post was previously on the Pathfinder Software site. Pathfinder Software changed its name to Orthogonal in 2016. Read more.

A lot of pair programming chatter this week. Starting with a New York times article describing pair programming at Hashrocket. It’s an interesting article, with a tone that could be described as “anthropologist describing the strange, yet quaint customs of the native tribe”

Obie Fernandez followed up with a list of 10 reasons why pairing doesn’t work in most cases. It’s actually a list of the things that Hashrocket does to support pairing, although entries like “2. Most software developers just don’t want to work that hard” and “1. Most software shops don’t really care about excellence” do have a certain, “aren’t we great” vibe to them, causing Mike Gunderloy to dryly observe: “Funny, Extreme Programming Explained never said anything about fancy hw or being awesome as a prerequisite for pair programming.”

C’mon Mike — everybody knows that being awesome is a prerequisite for everything in XP.

Josh Susser adds that pair programming isn’t right for all projects, particularly projects that have long compile times that force the pair to stare blankly at the screen.

I’d also add this interview with Kent Beck because a) every programmer could use some more Kent Beck in their life and b) because he talks about XP as being concerned with the social context of programmers, with pairing being a part of that.

Now you are caught up. Here’s the part where I talk.

I’ve had a running debate with Dietrich for two years now. He thinks that Pair Programming is the number one most important part of an agile team. I think it’s testing. That said, I do think pairing can be a nutritious part of your agile breakfast. But it’s tricky to do right and easy to do wrong.

Pairing is for the long haul. Like pretty much everything in the Agile toolkit, the real gain in pairing happens over time and is hard to quantify because it’s the absence of friction later in the project. The code is cleaner and easier to change. System knowledge is more distributed, so you are less likely to freak out when Fred catches H1N1 a week before.

Actually, I’d describe most of the XP practices as “we thought we were trading short-term productivity for long-term productivity, then found that we got short-term gains as well.” Certainly, can apply to TDD.

Project size and make up matters. A team of three developers, for example, is a challenge for an always-pairing environment. Even a team of two is a problem — some tasks really don’t lend themselves to pairing. If people on the team also has non-developer responsibilities, that’s another challenge.

Some people really don’t like it. And I think it’s glib to say “those people are lazy” or “those people don’t care about excellence”. Even I find pair programming really tiring, but in a “I worked hard today, plus I had to deal with another person all day.” It’s not unusual for programmers to be very strong Meyers-Briggs introvert-intuitives, and it’s not surprising that personality type would find pairing a challenge. It’s not insurmountable, but you do need to structure the pairing with people in mind — the Hashrocket 25 minutes on/ 5 minutes off thing is a good start.

While I’m here, I think you can really overstate the “people work harder with somebody next to them” thing. Pairing is great and helpful because of the continual review and talking about what you are doing. Conceiving pairing as a way to use peer pressure to keep your coders off of Twitter is, I submit, not very much in keeping with the spirit of the Agile Manifesto.

The physical layout is really important. A lot of Obie’s piece is about this. I just want to emphasize first that pairing is a lot louder than solo programming, and this can be an issue in open office environments, and also that pairing really does work better on a neutral environment that isn’t either developer’s home machine.

Pairing is hard to reconcile with offsite practices And I don’t mean just when you’re working with six guys in Krakow, but also any kind of work at home, flexible hours, programmer-friendly kind of time structure is a real challenge to integrate with pairing.

Hmm… A lot of challenges, not much guidance. Which matches my feelings. When put in the right context, pairing is fantastic. But the context can be elusive, even for people with the best of intentions and talent.

Would this have been a better blog post if I had paired with a co-worker?