Pair Programming Considered Harmful?

I love the company that I work at, so I'm not likely to let pair programming dissuade me from staying there, but when if and when I do look for a new job (or start my own company), I would be very wary of a shop that uses pair programming extensively. I really love working in a team and directly with others on projects, but pair programming can be very tedious, particularly if there is a big gap in experience between the two people in the pair.

We also use code reviews for all code that goes to production. I find this to be extremely valuable. For more complex pieces of code, we do 'design proposals' that are circulated within our small team (4 developers) to get feedback and improve the design of our code.

If you have skilled developers they will work more efficiently the less "management overhead" that is put upon them (processes, checklists, methodologies etc). They will simply self-regulate and a large amount of output of high quality. As the skill/experience of the developers in an organization drops management typically implements practices to better ensure quality. While providing checks and balances for the lowest denominator these will also typically slow down the best.

This is especially nefarious when you consider that a "great" programmer can be 10x (or more) as efficient as an average one. That's probably because they developed habits that make them so, and now you risk meddling with those habits. Making a 10x as efficient programmer 20% less productive can be costly.

The most insidious thing about this as top performers typically can stomach only so much "crap" that slow them down before leaving for another job. Which leaves the organisation with even less skilled workers that need even more "overhead" to control which in turn results in even more "good" employees leaving. Iterate a couple of years and you have an organization where it is very hard to do anything wrong but also almost impossible to get anything done because of all the committee's, best practices, etc

Of course pair programming is going to slow the best programmers down without adding much benefit. On the other hand for bad to average programmers pair programming will probably result in better code with will offset the reduced efficiency. From an organizational standpoint pair programming will reduce dependency on any one programmer.

It's up to every company to decide which trade-offs they're willing to make and balance that against the kind of employee's they have. Some lightweight practices might actually be beneficial even for the top performers but they do take some serious consideration to get right.

If you can manage it, hire really good developers and get out of their way.

I've always thought that for the purpose of improving code quality and transferring knowledge, a formal code review process is much, much better. Indeed, I've always wished more development shops would utilize a code review process of some sort.

1. http://www.spenceruresk.com/2009/03/impaired-programming-how...

On a personal level, I absolutely detest the very idea of fulltime pair programming, but I assume that its because of my personality. I hate it so much that when I was interviewing for gigs, the first thing I would ask is if they pair programmed, if they did, I'd politely remove myself from the running for that position with the company.

I have my moods, sometimes I want to work for 18hrs straight, sometimes, not so much. Sometimes I want to go down a rabbit hole that I know is stupid, I just want to because its exciting to try out possibilities. I hate that pair programming would seem to preclude all that (again I might be wrong).

I don't want to constantly be explaining why I'm doing something, it just seems tiring. It takes something I enjoy and turns it into 'work', where I'm just coding with someone, day in day out 8 hours a day. Good for the company I suppose.

I'm sure people love it though, what would be an interesting statistic to see is how many devs would pair program if they didn't have to.

Knowing that your mind is free to explore a problem to whatever depth is necessary is absolutely critical to solving something non-trivial.

I find it really hard to explain the damage of interruption to non-programmers. Whether it is a girlfriend or a client that likes to talk while you're fixing their bugs. I don't think it is necessarily unique to our profession, but it is certainly rare enough that most people seem not to get it.

I'm disappointed anyone still believes any of these Methodologies with a capital M will fix their project. All the techniques mentioned should be part of the toolbox, but it's up to common sense to use them appropriately. There is no substitute for common sense.

Still, I was pleasantly surprised after my considerable initial trepidation about reading a programming article on TechCrunch.

[1] or probably doing anything else creative, but I can't speak from experience

[2] and, let's not forget, communicate with the actual users of the software

I think many of us program at our best with a little solitude. Now, I do think "pair programming" can be beneficial with solving a particular problem but this is like something everyone should know just from life.

That said, one of the major techniques that Gawande advocates is the use of checklists, which can be useful even to programmers working alone to make sure they haven't missed some important step (e.g., verifying that their code works against a live server, vs. just passing unit tests). His article in the New Yorker on checklists is interesting in its own right:

http://www.newyorker.com/reporting/2007/12/10/071210fa_fact_...

One of the biggest problems we had was developers getting frustrated inside their pairs, because one of the members of the pair was weaker in some way, either slower, less experienced at the product, or less skilled generally.

Not only this but in a diverse environment with multiple cultures, where various disciplines vary, it managed to increase stress levels a lot also (as an anecdotal example, one of our colleagues was wound tightly and liked to be very procedural, while the rest of us were very laid back). These people all worked great on their own -- and got along -- but as soon as you pair them it all goes to shit.

"We sat down one morning," recalls Steele. "I was at the keyboard, and he was at my elbow," says Steele. "He was perfectly willing to let me type, but he was also telling me what to type.

The programming session lasted 10 hours. Throughout that entire time, Steele says, neither he nor Stallman took a break or made any small talk. By the end of the session, they had managed to hack the pretty print source code to just under 100 lines. "My fingers were on the keyboard the whole time," Steele recalls, "but it felt like both of our ideas were flowing onto the screen. He told me what to type, and I typed it."

The length of the session revealed itself when Steele finally left the AI Lab. Standing outside the building at 545 Tech Square, he was surprised to find himself surrounded by nighttime darkness. As a programmer, Steele was used to marathon coding sessions. Still, something about this session was different. Working with Stallman had forced Steele to block out all external stimuli and focus his entire mental energies on the task at hand. Looking back, Steele says he found the Stallman mind-meld both exhilarating and scary at the same time. "My first thought afterward was: it was a great experience, very intense, and that I never wanted to do it again in my life."

We pair with 2 monitors, 2 keyboards, and 2 mice facing each other with our own desks which I feel gives each person in the pair enough privacy and space to make us both very comfortable.

Is pairing intense? Yep. Is it worth it? Absolutely in my mind. The high quality of the code and the productivity is well worth it.

I think the other thing the author fails to mention is that in terms of up-skilling developers, the process of pairing is quite useful. Often the pairing will naturally raise the level of the weaker programmer by virtue of being exposed to new ideas and solutions by the more experienced developer.

Pair programming without dual keyboards and mice deserves castigation.