, 15 comments , ,

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!