Pair Programming Benefits: The Business Rationale
Editorial note: I originally wrote this post for the Stackify blog. You can check out the original here, at their site. While you’re there, have a look at their Retrace product that consolidates all of your production monitoring needs into one tool.
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.
Knowledge Work as a Wrinkle
Historically, this made sense. And it made particular sense for manufacturing operations with 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.