During the course of my work as a consultant, I wind up working with many companies adopting agile practices, most commonly following Scrum. Some of these practices they embrace easily, such as continuous integration. Others cause some consternation. But perhaps no practice furrows more brows in management than pair programming. Whatever pair programming benefits they can imagine, they always harbor a predictable objection.
Why would I pay two people to do one job?
Of course, they may not state it quite this bluntly (though many do). They may talk more generally in terms of waste and inefficiency. Or perhaps they offer tepid objections related to logistical concerns. Doesn’t each requirement need one and only one owner? But in almost all cases, it amounts to the same essential source of discomfort.
I believe this has its roots in early management theories, such as scientific management. These gave rise to the notion of workplaces as complex systems, wherein managers deployed workers as resources intended to perform tasks repetitively and efficiently. Classic management theory wants individual workers at full utilization. Give them a task, have them specialize in it, and let them realize efficiency through that specialty.
Historically, this made sense. And it made particular sense for manufacturing operations with a global focus. These organizations took advantage of hyper-specialty to realize economies of scale, which they parlayed into a competitive advantage.
But fast forward to 2017 and think of workers writing software instead of assembling cars. Software developers do something called knowledge work, which has a much different efficiency profile than manual labor. While you wouldn’t reasonably pay two people to pair up operating one shovel to dig a ditch, you might pay them to pair up and solve a mental puzzle.
So while the atavistic aversion to pairing makes sense given our history, we should move past that in modern software development.
To convince reticent managers to at least hear me out, I ask them to engage in a thought exercise. Do they hire software developers based on how many words per minute they can type? What about how many lines of code per hour they can crank out? Neither of these things?
These questions have obvious answers. After I hear those answers, I ask them to concede that software development involves more thinking than typing. Once they concede that point, the entrenched idea of attacking a problem with two people as wasteful becomes a little less entrenched. And that’s a start.
But a start hardly means enthusiastic acceptance. Really, it just means that they no longer shout, “balderdash” when they hear someone suggest the notion. They’ll have a conversation, but they still need convincing.
To make further progress with management requires a business justification. This holds especially true for management from more old school or traditional backgrounds. These folks tend to view programming as if it looked like manufacturing or construction. To win them over, you need pragmatic, dollars-and-cents arguments. In other words, from a business perspective, what are pair programming benefits?
Let’s take a look at tangible rationales that you can offer for adoption of the practice.
Have you ever read Steve McConnell’s Code Complete? If not, I highly recommend it for both programmers and people in and around the business of programming. The former will extract more value from it, but the book has wisdom for everyone.
One fascinating lesson from the book involves a study about defect reduction strategies, described here. Code review has extremely high efficacy for eliminating defects — higher even than automated testing. Now, let’s take that lesson and extend it a bit.
You can think of pair programming, in some sense, as protracted code review. Except, rather than happening once per day/week/release, it happens continuously. As a result, you can expect significant defect reduction per commit from a pair. Humans catch each other’s mistakes quite effectively.
As a business, you can project ROI by estimating cost of defects and degree of defect reduction.
Speaking of financial business concerns, have you ever contemplated the departure of a critical team member? Many organizations have a person who I’ll call Alice. Alice is a rock star who knows every nook and cranny of the codebase. In fact, it seems as though only she can reliably make things happen in half of the codebase. Should Alice leave, her departure would cripple the team.
Well, this situation has a cost, and businesses express that cost with a macabre metaphor: bus factor. Simply put, this is the number of team members that a bus would have to run over before progress on their work came to a halt. In less gruesome terms, you might also call it the “hit the lottery” factor. Either way, it has the same implication.
Pair programming alleviates this very real, very palpable business pain. If team members pair regularly, the bus factor grows to a nice, robust number as team members cross-pollinate their knowledge.
Let’s now look at another interesting benefit of team member cross-pollination. Not only does pair programming reduce the risk posed by a departing team member, but it also improves efficiency for onboarding a new one. Yes, pair programming benefits include making it really easy to onboard newbies.
I’ve seen teams where it took months for a new team member to do anything passingly useful. Existing folks spent all of their time putting out fires, so newbies had to learn on their own. And the codebases were so complex and fraught with weird, risky constructs that self-taught newbies didn’t get their hands dirty for a long time.
Pair programming completely eliminates that problem when adopted as a norm. In fact, these teams make the ideal situation for new programmers. Standard operating procedure would call for them to sit with experienced pair programmers on day one and immediately start doing useful things. The difference in efficiency of navigating the learning curve will amaze you.
I’ll offer one final benefit of practice that many might not consider at first. I say this because many would consider pair programming inherently distracting. You sit there with another human being that might interrupt your train of thought and prevent you from entering a state of flow. That’s true enough.
But consider this from another angle. The pair partner might stop you from entering a deep state of pondering, but he will also prevent you from opening Facebook and mindlessly scrolling through updates. The two of you will stay focused on the task at hand.
And then you have the subject of interruptions, the bane of a programmer’s existence. Consider that people performing random drive-by distractions are far more hesitant to interrupt two people than to just tap one on the shoulder. Even in the situation where the interrupter is undeterred, one of the pairs can deal with the interruption while the other remains focused. Context-switching murders productivity. So having at least one of the pair stay focused helps a great deal.
Is pair programming always worth the investment? Should team members pair all of the time or some of the time? Exactly how much benefit will you realize from pairing? I can’t answer all of these questions.
Team productivity and project cost encompass a dizzying number of variables, and contexts vary widely from case to case. I haven’t written this post to stump for pair programming as a silver bullet. And honestly, I haven’t even written it to stump for pair programming at all.
Instead, I wanted to point out that the practice does, in fact, have tangible benefits. You can’t dismiss the notion as simply as you could the idea of having two people use one shovel to dig one hole. Experiment with the practice, learn how it fits into your team, and take advantage of it to your benefit in a way that makes sense for you, specifically.
Stackify's APM tools are used by thousands of .NET, Java, PHP, Node.js, Python, & Ruby developers all over the world.
Explore Retrace's product features to learn more.
If you would like to be a guest contributor to the Stackify blog please reach out to [email protected]
