10 Reasons Pair Programming Is Not For the Masses

Hashrocket, or more specifically our beloved "Big Tiger" Jim Remsik, was recently profiled in the New York Times in an article about pair programming. They titled it For Writing Software, a Buddy System and it's gotten a fair amount of attention on Twitter, Hacker News and Reddit. (If there are other big discussions going on about it, please let me know in the comments. Thanks.)

I think pair programming is one of our most important competitive advantages at Hashrocket. My teams produce some of the highest-quality code I've ever seen in 15 years in the biz. We are able to effectively leverage XP-style client acceptance in our process because our code is so defect-free.

I'm damn proud of what we do at Hashrocket and talk about it often, but usually while trying to stress the supreme importance of context and talent in making it work. My homepage still says "Helping to evolve the world of software into a more fun and productive place to live, work and play", but pair programming, especially all the time, is one of those things where increasingly I have to advise most Agile idealists that it probably won't work for them, and here are ten reasons why:

10. Most software managers don't want to invest in the necessary hardware

Either they don't want to invest in the appropriate equipment (for personal or political reasons), or they are not allowed to do so.

Our pairing workstations are fully-outfitted Mac Minis ($1049) with a $99 Dual-link DVI adapter connecting them to an Apple's 30" Cinema Display ($1800). Each pairing workstation also requires a pair of mice ($98), keyboards ($98) and elevators notebook stands ($80). Finally, we also buy a pair of MagSafe power adapters ($159) for developer's notebooks. Mind you, we don't invest in all this fancy Apple gear because it's cool. We do it because we care about having the best tools available, a sentiment that the masses usually have to live without.

Incidentally, each of Hashrocket's developers has their own MacBook Pro, that they are required to own and maintain, based partly on the philosophy that a craftsman has his own tools.  That is a hard policy to pull off in mainstream software shops, because it can be seen as a turn-off for potential recruits, not to mention that most corporate IT shops suffer conniptions about not having control over machines that are connected to their networks. C'est la vie.

9. Most software shops are not configured for pair programming

Cubicles do not work for pair programming. Period.

Most office environments have cubicles and most software managers are stuck with the environment they have and lack the political or budgetary capital to do anything about it.

In order to effectively pair program all the time, you have to have the right furniture and workspace. Comfort is key. Big wide desks, comfortable chairs and elbow room. Our desks are 2 m x 1 m, cost about $600 each and are height-adjustable. There is enough room for the pairing workstation in the middle of the desk, plus dual notebook computers to each side.

There are no cubicles or private spaces available, because developers are not expected to work in private, nor are they supposed to be doing non-work tasks in the office. However, our office is partitioned into a number of "war rooms" and casual seating areas that can be appropriated depending on needs of the team. In particular, client calls are sometimes conducted in quieter areas.

8. Most software shops use traditional hiring practices

Relying on recruiters to source candidates and then hiring someone after a few phone calls and a day of interviews, you know, the way that most places do it, is one of the worst ways to bring on talent. You really don't know what you're getting. The savvy mainstream software manager might swing a contract-to-perm policy, but still has to recruit the contractor in traditional ways.

The best way to hire talent is to drop them in actual work situations for at least a week and see what happens. And that's the catch. Since most shops don't pair all the time, they don't have a built-in infrastructure to accommodate just "dropping someone into a real work situation". The poor candidate would be in over their head. Our candidates spend their interview week rotating on actual production code, pairing with the same people they'll be working with if they're hired. Everyone gets a say in whether to hire a new recruit, and hesitance from a developer that actually paired with them means they do not get hired.

7. Most software shops tolerate anti-social behavior (halitosis included)

At your average software shop, someone can be considered a "good programmer" even if they are a complete asshole. Nobody wants to pair all the time with assholes, even other assholes. Same thing goes for prima-donnas, chronic farters, people who don't bathe enough, people with halitosis, jerks, idiots, lazy bums. There are myriad conditions that could make pair programming a gruesome experience and it is absolutely management's job to make sure that those problems are kept under control or eliminated. As in censored. Or fired.

Face it, most software managers are under-staffed (see below), overworked and/or under-qualified. They would rather let the group deal with Asshole Architect, Mr. Stinky or Jimmy the office jerk than to go around provoking difficult conversations and making more work themselves. Besides, Stinky's code is pretty good, isn't it? Right... I've had to dismiss otherwise-qualified people for being assholes. People that I otherwise-needed. It wasn't easy, but it is crucial to do it anyway.

Full-time pairing requires strict implementation of the No-Asshole Rule. In the words of Robert Sutton, "enforcing the no-asshole rule isn't just management's job". The entire team has to feel empowered to call out and reject anti-social behavior. That kind of empowerment is extremely rare in corporate America. It's easier to take it during the day, rush out of the office at 5 pm on the dot and vent your frustration at happy hour.

6. Most software people don't understand pair productivity

Those of us that have seen it in action know that good full-time pair programmers consistently produce higher-quality code faster than individuals working alone.

To the average manager, with his average mindset, two people working on the same thing equals half the work done. To the average programmer, having to pair full-time means they won't get to waste time during the day on Reddit or Hacker News.

Full-time pair programming keeps developers focused and coding, all day, every day, week-in, week-out. The average developer spends maybe a few hours a day actually coding and finds all sorts of other activities to fill in the rest of his day. The difference in experience gained towards mastery of the craft adds up quickly.

I see pairing work so well every day that I consider my career prior to my current job to have consisted mostly of wasting time. When I think back to all the code I’ve written for a job, I’m annoyed at how much less efficient I was then since I wasn’t pairing, and how much better my code and my products would have been if I had paired on them full time.

When you have a second person working with you, you find that you try harder to code well. You’re far, far less likely to be willing to apply duct tape to a problem, because someone else is working with you and he or she is more likely to object to the duct tape. If two people approve a hack and implement it, it’s almost certainly because it’s the right approach given the time constraints. If one person sitting alone decides to pursue a hack, it’s more likely to be a situation where there is a better approach.

Two people attacking a design problem together is easier than one person doing it. Your partner will think of things you don’t, and vice versa. In a non-pairing environment, you can always call someone to a whiteboard to help you work through a design issue, but when you do that you’re only calling for help when you know you need it. The times when you need help and don’t know it go unaddressed – and yet despite the fact that you need help, I guarantee that you’re coding SOMETHING and checking it in. It’s almost certain to be shitty code. The amount of time you spend trying to figure out “what’s going on here” or “why isn’t this working the way I expect” is severely reduced. I’m talking hours of debugging that literally turn into seconds.

Rod Hilton in I Love Pair Programming

5. Most software shops employ under-qualified developers

Hashrocket is a boutique shop, so we can be very picky about who we hire. Candidates have to pair with us onsite for at least a week before the team decides whether to hire. We've hired qualified interns, but we don't hire apprentice or junior-level folks. Occasionally we do extended pairing matchups with client developers in our office, but they have to fit in culturally for it to work.

The bar for success in this industry is set very low. Most software shops have one or two great, productive hackers, offset by a boatload of net-negative producers:

"When doctors screw up (massively) they get sued. When (permanently employed) programmers screw up they get let-go, and they go find a new job, usually with more responsibility and a pay raise. There are no ramifications for software malpractice." 

Jay Fields in The Cost of Net Negative Producing Programmers

Hiring only great people and compensating them very well is expensive. Most software managers don't even buy into the advantages of only hiring great people, thinking that a mix of talent levels is more advantageous.

4. Most software shops are overworked and under-staffed

This reason is related to #5 in the sense that most software shops don't have enough good people to take responsibility for the truckloads of work that they're expected to do. You can't put idiots in charge of important projects, therefore pair programming requires double the amount of "good" people as not pair programming.

Promiscuous pair programming, where there is a weekly, or even daily, rotation of pair partners, requires more people than discrete workstreams, so that pairs can switch without incurring big ramp-up penalties.

3. Most software developers don't like everyone they work with

Good luck putting together more than 15 people in any type of group without some of them hating each other's guts. Now limit your pool of resources to average programming geeks with anti-social tendencies and making your group get along just got a lot harder.

Lots of teams out there are simply too big for a happy group to even be possible. There is research on ideal group sizes for teams, with the consensus falling in the 8 to 14 member range. Unless you're committed to small teams of sociable people, you won't be able to get everyone working together happily. 

Most software managers would rather pay 20 mediocre and/or anti-social developers $75k/year instead of hiring 10 great developers at $150k/year. (Why? I'd bet on they don't want to pay their developers more than what they make.)

2. Most software developers just don't want to work that hard

Laziness is a virtue for programmers, isn't it?

Laziness - The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful, and document what you wrote so you don't have to answer so many questions about it. Hence, the first great virtue of a programmer.

Larry Wall in Programming Perl

Unfortunately, it seems like over the years as an industry we've simply reduced that advice to "go to great effort to reduce overall energy expenditure" and forgotten about the rest.

Pair programming makes developers work harder than they've ever worked before in their lives. You constantly have someone making sure that you're not distracted or wasting time running down dead ends. Unless you're an asshole who just doesn't care (see #7) you're not going to abandon your pair while you endlessly do non-work-related stuff. Pairing keeps you honest. Being honestly hard-working is still one of the best ways to earn accolades and raises. Accolades and raises usually bring some measure of added happiness.

All that hard work really pays off in terms of success for everyone involved as well as personal growth, but why bother trying? Most software developers are happy to skate along doing the least amount of real work possible without getting in trouble. In other words, they're lazy.

1. Most software shops don't really care about excellence

There are so many things to worry about at your average shop that have nothing to do with excellence. Corporate America cares about lines of code, the bottom line, toeing the line, and whether Joe in Accounting is doing lines in the bathroom during his breaks.

Truly caring about excellence means considering your work to be more than just a job or a paycheck. You have to treat is as a craft. You have to have passion for the success of your clients, company and co-workers. You have to be justly rewarded for that passion and encouraged. You have to care. And frankly, that is just way too much to ask of most people.