Reflections on 10+ Years of Pairing – What Works, What Breaks, and What’s Next

Article summary

standup-pairing

I started pair programming in 2000 on my first real software job, while I was still working on a computer science undergraduate degree. I’ve been mostly pairing in daily practice since then.

First Impressions Matter

My earliest perspectives on pairing are useful because I’ve seen bad results when people are denied the chance of finding out its benefits for themselves. Pair programming wasn’t prescribed or preached to me, it was encouraged.

I didn’t see it at first, but came to notice how different my experience was than most other developers I met over time. I met many developers who’s first experience with pairing was having it prescribed by their employer or through an introduction during university study. The big difference is that it was introduced to me as an experiment. It had already been laid out as a practice in Kent Beck’s Extreme Programming, but it wasn’t common or tested enough to be recommended yet — we were just seeing how it worked. So for me, pairing came with an element of pragmatism right from the beginning.

The result was that while I was hooked, it wasn’t because of a rising trend or a glowing review from a peer, and definitely not because I was required to “try it” by a manager.

It didn’t take long to see the positive benefits for myself. Of course, it also wasn’t long before it was prescribed where I work, since we saw the benefits clearly enough to deem the experiment a success.

It’s been a long road from there, and the practice and story of pair programming has certainly evolved since then. What did I learn along the way?

Knowing When it Works

Rather than claiming “it’s easy” and espousing benefits, or looking at more obvious metrics like team and product success, I’ll list some keystone questions you might ask of a team to evaluate successful pairs.

Can you ask anyone on your team about any part of the code and get an informed answer?

Knowledge sharing should be the natural result of pairing. If you have silos, you’ll also get dissent and occasionally mistrust about implementations, or disagreement about decisions made in isolation. Code reviews and pull requests can mitigate the lack of knowledge sharing for remote teams, but they’re ultimately workarounds used when teams can’t work together and share knowledge directly.

Are any parts of the app critically dependent on a single developer?

Silos begat silos! It doesn’t have to be about job safety. In some cases people are simply unwilling to “take over” where someone else has already established a direction. Pairing lowers the barrier to conversation and collaboration, preventing risk of echo-chambers and lowering your so-called “bus number.”

Does your team have a “policy” about pairing?

A policy is a smell indicating that members can’t see the benefits for themselves without a mandate. Consider each new team member as an opportunity to question how well pairing is working for your team and strengthen the practice, not as a target for policing.

Does the product owner recognize multiple team members as responsible for success on each feature?

An analogy from retail sales: wouldn’t you feel better served if two members of staff were helping you, conversing about your needs? A great sign that pairs are taking real responsibility is that the customer knows that multiple people are capable of owning delivery for a feature. This “pair transparency” is a natural benefit of an effective pairing process. Don’t delegate customer interaction to one person in the name of efficiency. Software is way more complicated than picking out merchandise: it’s worth having two heads to navigate a customer’s acceptance of features!

…and more

Don’t consider my list complete — I don’t! Pairing is a deep practice you can always improve on. Find aspects of pairing that have helped in the past and apply them as yardsticks for the future. You’ll find some heuristics to be consistent, and some ephemeral. But you’ll definitely learn something!

Pair ALL the Things?

I eventually saw one common negative experience was simply taking the suggestion too seriously. Some developers would relate trying out pair programming as an attempt to gain something lost (productivity, team connection, whatever) and then quickly drop it. I saw this often enough to notice that a common problem was trying to enforce pairing as a rule on it’s own, without letting people decide for themselves when it would make sense or when it was excessive. We’re extreme, right? Turn it up to eleven, they said.

In my experience, this was too heavy-handed and provided a tempting scapegoat for poor results: “the new practices must have failed!”

For me, rather than explain pair programming as a practice to be enforced, I would simply set an example: “I’ll pair with you on this.” Some work would be done without a pair, and it wasn’t hard to see that work result in more time spent explaining the results to peers. The primary benefit, to me, of pairing is shared knowledge. Demonstrating this isn’t hard, it just requires someone willing to ask and then point at the result, saying, “Now let’s pair on this next…” The less-experienced pair will either see the benefits or move on.

Knowing How it Breaks

As with any tool, mastery requires an intuition for which applications are effective. When learning the right time to apply pairing, it helps to know some of its failure modes.

Know when you’re just “rolling the dough.”

There’s a time in over-long meetings where everyone in the room feels its utility has ended. I think the same sense can be developed for when you’re pairing on tasks that could be done solo, or vice versa. Here’s a couple of signals that it might be time to start or stop pairing:

  • Is my pair easily distracted? Am I?
  • Am I discovering something new, or making a decision?
  • Am I stuck?

When these arise while I work alone, I might seek a pair. When these arise while I’m pairing, I might suggest that we take a break or find a set of tasks to tackle separately before trying again later.

That second bullet is subtle: I’ve often realized only later that some code I wrote was actually setting a design direction with larger impact. For me, this is another reason to prefer pair programming, even if I try to avoid prescribing it.

Watch for “The Exception.”

Another observation that took me a while to pick up on was how fragile pairing success can be. One indicator was the impedance mismatch you’d observe when a practitioner was trying to convince a skeptic of pair programming’s benefits. They might not know the root causes of their pairing success, and they’re too busy evangelizing to stop and explain when it doesn’t work. One such blind spot is that, like creativity and optimism, the atmosphere where pairing can succeed is easily sapped by one sour apple.

All it takes is one team member to decline, consistently. There are plenty of reasons: lack of interpersonal skill, required “hammock time,” or seeking “flow.” Whether used as an excuse or as a legitimate case, my experience is that they can single-handedly poison the pair programming pool in their team by simply saying, “No thanks.”

This can destabilize a team like a spinning top hitting a pebble on the table.

To help pair programming succeed, find a place for dissenters to work elsewhere. They might be valuable to your team, but they won’t help it get value out of pairing by rejecting it — even casually — and their attitude can become an excuse for the whole team to avoid the practice. Relocation can be of mutual benefit since, presumably, the person in question would rather work alone. This is a situation where pragmatism can help pair programming work: plant the garden, but pull the weeds.

Of course, you might try to avoid hiring these types in the first place. This can be tricky because a developer might be willing to try pairing but then discover a reason to object. If they end up being the type with stubborn ideals, it’s best to find a comfy home for them away from your pairs.

What I’d Do Differently

Pair thee well?

Looking back, one situation pairing can make worse is passivity. If some team members are unwilling or unable to broach the topic of changing something, working directly with someone they disagree with won’t help. Not just for this reason, I think introspection and honesty are keys to pair programming. If your team is navigating a political pathway, climbing corporate ladders, or dodging critical peers, they won’t be honest with each other about communication problems, and you’ll end up with the 2x cost you were trying to avoid.

Establish habits to deter distraction.

As social networking and developer laptops became prevalent, the distraction level a pair must deal with has increased. I think that establishing individual habits is the best way to set expectations about handling email, Twitter, or Facebook within pairs. If one member of the pair churns through features while the other peeks at browser tabs, they’ll get the message quickly enough. If not, rotate pairs more frequently to raise the level of activity.

Making a policy is tempting but could be a trap, ultimately squashing the flexibility and pragmatism successful pairs will require.

Don’t pair on multitasking.

Pairing is two people working on one goal through mutual implementation. If you are working on two goals, that’s just called “sitting too close.” The knowledge sharing isn’t part of the agreement then, and ownership and expectations will still end up individual. While this might work short-term, there’s a trap in assuming that pairs can work “together” on separate tasks continuously.

Ten More Years?

I think pair programming has been and continues to be valuable. Looking on the scale of decades though, how could it change or fall out of practice? I have a few wild predictions I’ll share…

Collaborative Environments

As coding skill disseminates, environments unify, and languages get more capable, so will collaborative coding become more viable. This will look less transactional and physical than what we call pair programming today, but it will build on the same lessons of immediate feedback, human communication, and shared ownership.

Off-desktop Programming

How long do you think it will take to convince coders to write software from alternative devices like tablets or headsets? 5 years? More? It seems inevitable, and it will likely change the landscape of personal interaction in software teams.

What Else?

I’d love to hear your own success stories, lessons, or speculation on the future of pair programming!