The Pair Programming Skeptic
I pair program full-time at Pivotal Labs. That’s two developers, one computer.
I’ve found pairing to be a highly rewarding experience for myself, my teams, and the entire business. But it’s still a relatively unusual practice in the software industry, though at Labs folks are working hard to change that culture.
Nonetheless, we often get pushback from folks about pair programming when we first introduce the concept.
We tried pairing, but it didn’t work.
Our productivity dropped to half and everyone was unhappy.
Aren’t you just wasting resources by having two people do one developer’s work?
It’s a story I’ve heard many times. But is pair programming to blame? Or is something else going on?
Pair programming is a hard skill to learn. It’s easy to be skeptical of pairing, but I have the opposite experience now: I think solo programming is a tedious and inefficient activity. But like all good things, pairing requires some dedication and hard work!
Let’s explore some of the common objections to pairing I’ve heard over the years. There’s a grain of truth contained in all of them. But I’ve found that the benefits and gain in productivity vastly outweigh the challenges in getting to effective pair programming.
My Pair Will Slow Me Down
Surprisingly, I deliver software faster and with much more focus when I’m pairing. I really value the ability of an experienced pair programmer to act as a real-time sanity check, a second well of knowledge, and mild “peer pressure” to stay on task and do the right thing.
But I’ve experienced this before once or twice: the programmer who just doesn’t seem to “get it.” I paired patiently with someone like this day in and day out over the course of months, and I’m still not sure if anything stuck. In over two years of pair programming, though, this is a very rare exception.
Pairing doesn’t automatically solve the problem of a developer lacking some skill, experience, or context in an engineering organization. However, it does expose those imbalances early, and provides an excellent infrastructure to address this gap. Not only is addressing these gaps while pairing a kind thing to do, but it serves to speed up the development of the whole team’s productivity, raising the bar for the entire group.
Everyone comes with different skills and backgrounds, and differs in pace and preferences. But pairing helps to smooth out those differences in the long run, because when both of us elevate our game, the overall skill level of the team rises.
Pairing Disrupts Individualism and Creativity
Actually, the value of individual contributions and creativity is very high in pair programming situations. But not in the way you might think.
Pairing requires you to disrupt certain kinds of individuality. But most of the time these are the kinds of things that matter the least, because they are the kinds of individualisms and idiosyncrasies that get in the way of team productivity. In order to get to productively pairing, you have to give up some of your personal preferences.
Tabs or spaces? Vim or Emacs? Editor wars, OS wars, browser wars, language wars, you name it.
You’ve probably heard loud and violent debates on any or all of the above. But when you and your pair (and by extension your whole team, because you’ll want to rotate pairs around) resolve these issues early, and then learn to let it go because it doesn’t really matter, you can begin applying your precious brain cycles to problems that you actually need to solve.
So you’ve given up some of your personal, more trivial preferences. Now what do you do when you and your pair need to solve the actual hard problems? It turns out there’s lots of space for both individual creativity in pairing, and for the power of a balancing point of view from your pair.
When I have a crazy, creative idea, I might jump to try it out if I’m soloing without thinking about it too hard. But if I’m pairing, I first have to convince my pair why this crazy idea is worth our time to try out. If you can manage to do that, setting aside your egos to try to solve a problem together, your crazy idea will be doubly vetted…or debunked! That’s the power of pairing.
You Can’t Force People To Pair
Okay, true! But…you shouldn’t really “coerce” people into doing anything, should you? That just isn’t the kind thing to do to your workforce, if you value their happiness and well-being. People should want to do the right thing, and it’s on the organization to promote a culture of collaboration as the “right thing.”
But it’s hard! Pairing makes you vulnerable, requires social and communication skills, requires you to give up your ego for the greater good, and it can be tiring. You cannot force people to do these kinds of things, lest they feel threatened that their way of life, or even their very identity, is on the line.
We have to ask our developers kindly for their attention and time to pair. Just like we do all the time when we’re pairing! “Do you mind if I take the keyboard for a second?” Asking your pair to comment on and agree with your combined actions requires both of you to communicate and align on your goals and directions early and often.
You can’t force people to become willing and experienced pair programmers. But if your work environment is supportive and encouraging of collaboration, values driving consensus and alignment, and has a management and reporting structure that supports improvement and feedback, then pairing will feel a lot more natural to your team.
Pair Programming Is A Waste Of Resources
If you value “theoretical maximum lines of code typed per minute” as a key resource, then yes, two people at one computer is a waste, though I question how useful that metric is on its own!
But what about everything else? What about productivity lost to unfocused solo time checking e-mails, browsing the internet, or social media? What about time spent in technical meetings and code review sessions which break people out of their flow to inform them about areas of the code they don’t touch or own?
What about the cost of recovering lost context when you lose an experienced team member to vacation, or permanently? What about the cost of asking a new developer to sit by herself for a week attempting to “read through” the codebase in order to get productive? What about the cost of asking your most senior technical folk to spend their time enforcing code quality and discipline?
Pair programming is a practice that dramatically reduces the cost of time lost to pretty much everything outside of the physical act of typing: communications overhead, review processes, enforcing code quality, and routine changes in staffing. Think of pairing as an investment in your developer workforce and culture, to help reduce the cost of change and increase the pace and quality of delivery.
Pair Programming Isn’t A Miracle Drug
Pair programming is a skill that, when combined with other elements such as co-location and test-driven development, can help solve challenging problems of communications, context sharing, and alignment in teams. It helps smooth out productivity to improve predictability and also functions as an investment in the professional development of your workforce.
But pairing doesn’t solve problems on its own. Just like any other investment in process, pairing is as much about what you put into it as what you get out of it. This is really the heart of many objections to pairing I’ve seen.
It’s hard to “try a little” pair programming and find it effective. But if you’ve been bitten by the pairing bug like I have, it’s hard to go back! After all, software development in a team is a social activity by nature, so why not code together, too?
