Pair programming sucks. That’s okay.

Pair programming is fundamentaly as simple as it sounds, but in practice it has many layers.

You know, one way to look at Agile is to observe that it’s simply an attitude that recognizes that software is done by real people who have complicated personalities. Tasks don’t get done just because they’re next up on the Gantt chart, they get done because a human person has his or her head together enough to think clearly and figure them out.

That’s the nature of creative work. Thus, you’ll often find that production doesn’t equal resources multiplied by time on task. If you care about your project, cultivate the conditions that help yourself and others do their best work. And pairing, done well, helps bring about such conditions.

What they don’t like

Here are three complaints I often hear about pair programming. They all contain some truth, but they shouldn’t dissuade you from giving pairing a serious, sustained effort.

Pairing is a waste of labor!

Mathematically and simplistically, sure. Two programmers working on the same stuff aren’t always going to get twice as much done as one programmer. It’s kind of a Brooks’s Law or diminishing-returns thing. In terms of how many lines of code get written, it probably is a waste of labor.

But here’s the thing: Your goal isn’t to write lines of code. Your goal is to create software that solves an organizational need, and the lines of code that you have to write and edit, write and edit… are the ones that don’t achieve that goal.

Simply having that second pair of eyes on the task makes both developers more effective. How’s that? Keep reading.

The takeaway: In the very short term, you probably lose some productivity. But it comes right back to you in quality and rapid learning. Figure a one-week payback period in many cases.

The dumb person slows the smart one down

Again, there’s some truth to this, once you get past the implied criticism of “the dumb person,” who most likely just doesn’t know the existing code base so well or is new to the development environment. If the “smart” person is driving the keyboard and mouse, he or she is interrupted by questions or alternative solutions.

But the dumb person isn’t that dumb. Every question is a reach, a way to learn fast. Much faster than reading manuals or waiting for help. And the dumb person knows enough to shut up and watch when the smart person is on a productivity tear.

Bottom line, if the dumb person isn’t slowing the smart person down a little bit, you’re doing it wrong. The idea is for the dumb person to absorb as much information and technique as possible, for the dumbness to go away. It really does work—rendering the smart/dumb friction moot.

The takeaway: You’re not being slowed down. You’re layering teaching with direct, hands-on practice. It’s far more efficient than having to explain things all at once.

Cube-crowding is uncomfortable

Yes it is!

Nobody wants to say it, but there are all sorts of tensions in these circumstances. Normal cubicles aren’t built for two people at a desk. People have different grooming and cleanliness standards. I always worry about my breath. Depending on a lot of circumstances, mixed-gender pairs can feel awkward. You might be paired with someone you sincerely dislike, or whose political beliefs freak you out. And so on.

Recently received from a past client/colleague:
When I took on an Oracle .NET project without knowing where to begin, let alone how to code in C# or JavaScript, definitely the most efficient way to learn was to pair up with you. Of course in the beginning we were not “pair programming,” because you were doing all the work, but after a few weeks I was able to start producing some of my own code and making sense of the overall structure. Having you at my elbow to encourage, correct, and suggest made the process very workable. In the end I was able to take over and finish the project, and I have been maintaining it ever since.

Sharing your computer too… sheesh. You want to keep your email open, and then there’s this Outlook popup from your ex. Or you were going to pay some bills online before noon.

But besides that, at work your cube is your castle! It really is a pain to have someone in your space, making demands and telling you how to do your job. Seriously. Even if you really like working with that person. I get it. I hate it too.

There are two mitigating factors though.

One mitigating factor is that you don’t have to pair all day. Seriously. It’s fine. I do all-day pairing once in a while, but usually the energy for it just isn’t there. Simply working in close quarters with one other person is tiring. (One-on-one tutoring is harder than teaching a class, too. Same reason.)

You can get quite good benefits from pair programming for two hours a day or so. More than… oh, about six hours? Usually feels like too much. Pay attention to your sense of personal space, and what is actually productive for you. It’s usually pretty obvious when you’ve been in each other’s faces for too long.

The other mitigating factor is the nice switch of energy between pairing times and solo times. It is amazing for getting out of ruts. If pairing feels like a rut, break up the pair and work alone for an hour or two. If working alone gets you into a rut, rejoin that pair partner or find another one. It’s like waking up on a new day, except without messy hair. Also, it wouldn’t hurt to open up those cube walls after all.

The takeaway: Yes it’s uncomfortable sometimes. What you gain in energy-switching more than makes up for it. And if it really bugs you, just switch off pairing for an hour or two. You’re allowed.

Do you want to try Pair Programming in your own shop? Get started with that, and other Agile practices that are easy to get started with and most immediately effective with my Emergency Agile process!

14 thoughts on “Pair programming sucks. That’s okay.”

  1. Nice post Mark!

    I’d add that the “dumb” person is also going to bring a fresh perspective and approach to the problem. The “smart” person may be so used to doing things a certain way that they aren’t thinking about as many different options. The “dumb” person, who doesn’t know how it is usually done may ask questions or suggest strategies that seem odd, but actually lead to a creative solution.

    That happens when I do training. Someone will ask if they can use X to accomplish Y and it will be something that hadn’t occurred to me before. Then together we ponder how that might work and then we both have a new trick up our sleeves. In the end, we really do all learn from each other, and if we don’t work with others of different backgrounds or skill levels we miss out on new perspectives.

  2. Yes! Which also ties into the Agile concept of failing fast. If the “dumb person” has an idea that turns out to be unworkable, fine. He or she has learned and everyone can move on with a clear understanding.

    The alternative is to leave the “dumb person” resentful, grumbling about being ignored.

    Several times I’ve asked people, outside of a pair environment, to go ahead and implement their concept that I knew for a fact could not possibly work. It was much faster and easier than explaining why they were wrong, and I didn’t have to be the jerk who wouldn’t let them run it out.

  3. The dumb person slows down the smart person?
    Maybe, that is not even important as the speed of the team is dictated by the slowest person, not by the fastest person.
    I agree that doing 2 hours a day is better then nothing, I advice teams to try it out 2 iterations to do at least 4 hours a day. For everyone.

  4. Yves,

    Does the slowest person really dictate the team’s speed? I think that only applies when it’s something that has to be done in unison. Like log-rolling or pulling a really big sled.

    That reminds me of a long-ago job where we were only allowed to write code that “everybody on the team could understand.” That’s not so crazy, but the team included a couple of people who seriously couldn’t be bothered to learn all the language fundamentals so obeying that rule would have resulted in some bad pidgin. (So we ignored it.)

    But I agree that the productivity gain from boosting the slower person can be huge. It’s worth the (potential and temporary?) cost of slowing the faster person.

  5. The team wants to achieve the sprint together.
    Yes in my opinion the speed of the slowest person dictates the team speed.

    If you things sequential that is even more true then when you do things together.
    It’s the whole idea of theory of constraints.

    The bottleneck game makes this very visible

    Even if that is not true, let’s look at it differently.

    You might improve the speed of your smartest person by 10%
    That is a lot because he is your smartest person.

    But your slowest person, I’m sure you can improve his speed a lot more.

    And that is a one time investment, that should help the whole team.
    (Because with PP you will improve everybody, not just the dumbest person.)

    Jeff is great in Java, Peter is great in Business, Vera is fantastic at Unit Testing, and Junior knows all the shortcuts from Eclipse.
    Who is the dumb person in this team?

  6. @Yves, I think you understand it better than I do. Thanks for the contribution; it makes a lot of sense.

    @Karl, what a great reference. I should be subscribing to the IEEE publication anyway… now there’s some motivation!

    @Dahlia, I’m doing my best. Cultivating Agile children too. 🙂

  7. Pair programmer keeps me out of the zone, and thus unproductive. I can write code faster, and better quality without someone buzzing in my ear.

    It is a noisy, annoying and downright terrible environment to work in.

    If I need someone to talk through some issue I am having, that is one thing. But to force me to work in pairs, no thank you. I would rather be underemployed than be forced into such stupidity.

    1. I 100% agree with the person above, saying pairing is a waste of time. I have done it enough to see that it is less productive, and much more expensive. I absolutely hate constantly being interupted by the guy sitting right next to me whilst I am trying to work out a solution in my head. And don’t say that I should be discussing it with my pair and working it out with him, as sometimes thinking is actually better than talking. Additionally, sitting at a 45 degree angle to the screen doesn’t particularly feel confortable.

  8. Pair programming has its benefits but make no mistake it has a great many drawbacks as well. Most of which can’t be written off with a simple 4th grade line of reasoning like the rubbish I see in most of these pairing support threads that try to shoot down all of pairings cons. Let’s be real.

Leave a Reply

Your email address will not be published. Required fields are marked *