Last time, we talked about the different flavors of two sets of eyes. They exist on a continuum that we see as:
The last two options on that continuum are flavors of pair programming (or “pairing” for short):
We define pairing as two developers/designers working on the same code on the same machine at the same time. Yes, the same machine, at the same time.
You’ve probably heard of it, or you may have done it. Unless you’ve been asleep for at least the past decade, though, you’re probably aware that pairing is hotly debated among people involved with software development. You’ll find vocal detractors and defenders without looking too hard. Which opinion is right?
We frequently side with the defenders, with one caveat: Pairing only makes sense when it makes sense. We don’t do it all the time. We’ve had great results with it when it made sense, and we’ll gladly defend it as a practice in those cases. As the African proverb says, “If you want to go fast, go alone. If you want to go far, go together.”
The objections to pairing aren’t new. In fact, most are reasonable, given the perspective of most software development project managers. One blog post isn’t enough to cover every nuance, but we can address some of the most common objections and give our perspective on how accurate they are.
Despite what vocal devotees of pairing claim, this is reasonable point. It makes sense for a manager to critique the additional cost of having more than one person work on the same code at the same time. The problem with the objection is that it ignores (or seriously discounts) the economic gain of pairing, and it exaggerates the costs.
The economic gain of pairing comes from four primary sources:
The challenge is quantifying that economic gain, because true comparisons aren’t feasible. How many companies do you know who are willing to do the same project twice, once with pairing and once without, and then compare total costs? We don’t know any.
Even if that comparison were possible, it still wouldn’t be entirely accurate, because you’d need the same team to do the same project twice so you could measure the independent effects of pairing. But the team would be smarter after doing it the first time, and the approach they used for the second try would benefit from that. It’s not comparing apples to apples.
Our experience tells us two things:
In fact, some empirical research shows pairing adds about 15% overhead cost (not 100%), but reduces defects by about 15%, which can lower overall cost of a system. You need to decide which costs more. It could be a wash, which would suggest that the other upsides of pairing could add up to a non-trivial economic benefit for your organization. (see https://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF)
It might, at least in the short term. Pairing takes time to get used to. Knowing how to be a good “driver” and a good “navigator” (the two pairing roles) takes some experience. With practice everyone on the team can be good enough at pairing to reap the benefits.
Many objections about team speed miss two important points:
In our experience, pairing can increase team efficiency and quality. We’ll trade that for a near-term speed bump while developers on the team increase pairing skills.
This depends on the developers.
There is no denying that some developers detest pairing. They’ll quit rather than do it. If you have enough developers like that, you can choose not to use pairing. You might want to consider, though, why your developers are so opposed.
We often find that opposition comes from two common sources: developer arrogance and fear.
Genius jerks are common in software development. They believe they’re better than others, and being forced to pair with developers of lesser skill damages the genius’s ability to produce. They may be right. Perhaps they really are that much smarter than the rest of your team. Then again, maybe they’re unjustifiably arrogant. Pairing should prove which it is. Nothing humbles a developer like having a pair point out something he missed, or hasn’t thought of, or is mistaken about. If you have arrogant team members, it might be time to encourage them to move on.
Fear is every bit as common. Writing code is hard. It can be challenging to keep current on everything you need to know. No one wants to be embarrassed, so developers often use solitude as a defense. If nobody sees your code, nobody can judge your code before you want them to do it. But do you really want terrified developers on your team, or do you want a team of people who build each other up and become more confident over time? We’d rather have the second one.
Agreed, so don’t. Pair when it makes sense. Don’t pair when it’s not smart to do so. For example, pairing on research doesn’t make sense. Split up, research, then come back together to compare notes. That’s a good use of time.
We’ve never recommended pairing on every task. Sometimes you don’t even have to pair when writing code, although we very rarely release any code without two sets of eyes on it, either via pairing or code review after the fact. Objecting to pairing because it’s not a good activity for some tasks is objecting to pairing done wrong. We object to that, too, but doing it wrong isn’t the only option.
We’d be first to admit that a team with large skill disparities can have trouble pairing effectively. You’ll typically end up with essentially a driver and a passenger, or maybe a backseat driver (where the navigator tells the driver what to type). Neither situation is good in the long run.
This can be a temporary problem, though. Those with lower skill will raise their skill level over time. It doesn’t happen overnight, but pairing with those of a higher skill level can ramp up people’s skills rapidly, much faster than sitting in a classroom. That will pay off for the team, maybe sooner than you think.
Note that this assumes your higher skilled people are good teachers. That’s not a given. If they are, your team can probably handle the wide gap in skill levels. If they’re not, the team could suffer.
Managers often say this, and it’s true. Some people refuse to pair. Managers shouldn’t dictate pairing as “the way we’re going to do things from now on.” It probably wouldn’t work if they tried.
That said, a smart manager might drool over the potential benefits of pairing and wonder how to get folks to do it. The short answer is that you can’t force anything. Here’s where you face a decision, and what you do depends on your role:
If you think pairing when it makes sense is the right way to go, you may have to fight for it.
Pairing won’t magically fix what ails a team. It’s not the wisest approach in certain situations. It’s not something every programmer wants to do. It’s also not something management can impose on unwilling participants. No silver bullet here.
That said, we favor pairing over the other approaches because it tends to maximize communication efficiency, maximize code design quality, and minimize rework. If you’re interested in those things, try pairing when it makes sense (which might be more often than you think). The results might surprise you.
