Pair programming review

I've been pairing for about two years now with a broad array of partners-- I came to work for a startup whose policy is "all pairing, all the time" for any code that goes into production. I was pretty leery of the practice initially. What I've discovered is that pairing is just like anything else: it depends completely on the people involved.

There is no faster way to get bootstrapped on a new technology or codebase. Period. This is not a junior dev/inexperienced coder argument; finding all the holes and tweaks in a new library or package takes time regardless of how good you are-- if you're pairing with someone who knows the new tech (in my case, it was RSpec) you're getting constant guidance, tips, and corrections.

Pairing can help stop you from putting stupidity in the code. Many, many times I've been called out for trying to take a shortcut, skipping or forgetting a test, or just making a dumb mistake. It's a little appalling how many brain-dead dumb mistakes programmers make (Yes, that includes you. It doubly includes you if your first reaction was "I hardly ever make mistakes!").

Code quality is worlds better. Programmers tend to pick the first solution they like and implement it; pairing forces you to justify that decision.

Focus is much, much higher. When solo progging (for side work or personal projects) I've noticed I tend to defocus when I hit a hard problem I need to think about. This is the danger zone where I may click over to my email or twitter feed "for just a second" while I'm chewing on a problem.

You back out of dead-ends a lot faster. Getting stuck looking up some arbitrary or incomprehensible behavior in a library is far less frequent and painful when you've got two people working on it (one of whom may already know how/why something is happening).

There are a number of other benefits that you can find in any discussion of pairing, the above are the big benefits that stand out to me.

That said, there are a couple people pairing will not work for:

Mr. "This will never work." Self-fulfilling prophecy, enough said.

Complete incompetents: these are rarer that you might think, but you just can't drag someone along in a pairing situation. Before long they'll be surfing fark.com while you do the work.

Bulldozers: Some folks just pick a "solution" and will implement, fight for, and force that solution at all costs, no matter how bad it is.

The Lazy: Fights tend to crop up when one person wants to do something the right way, and the pair partner's argument is basically "But that's a lot of work!" This is where you usually see disagreements crop up about "over-engineering" vs. "sloppy code."

In short, pair programming can be a wonderful practice that produces super-high-quality code in a fraction of the time. It takes dedication and effort from both partners. I think a lot of programmers fear it because they worry they'll be outed or labeled as incompetents or slugs-- it pays to remember, though that the point of pairing is not to engage in a mutual junk-kicking, but to finish work, improve the code, and improve both programmers all at the same time.

In the correct setting where one in the pair really needs help it's very useful. The equivalent of grabbing a team member and say "I need some input here, will you take a look at this code/problem?". Like it was long before "Agile".

But to be forced into pair programming with forced rotation scheme every single day year after year is nothing but torture.

I would add:

Often employed at consultancies where it allows them to charge twice the rate for half the productivity

He would define a set of requirements, I'd code them up and iterate releases every day or so. He'd use it for a day and either while using it, or after gathering up some notes, give me the next round of requirements.

Our release cycles were measured in hours not days and we went from prototype to working-in-a-production-environment in a month.

The technology we built in those three months was either bug free or all the known errata were well documented, we had manuals, well commented code, design documents, methods and operation manuals, and real world working results. It replaced a major component written a couple of years prior by a team of three developers with a faster, more robust, more portable, more extensible piece of code that coupled more tightly to the subject matter requirements while still being flexible enough for other domains. It was ported to Java by a major systems integrator for use as a critical infrastructure link between components on a $150mil/year contract and some of the components and lessons from it became important pieces in a number of other pieces of software and solutions. Another port was made for a web deployable data processing engine on another multi-million dollar contract.

It was without a doubt the most prolific, most rewarding and most productive project I've ever been on bar none and I'm convinced that it was the extremely fast cycle time from requirements to working code that did it.

Along the way, what we discovered is that the fast iterations quickly made us realize that requirements we thought were important initially weren't, and new important ones emerged quickly. If we had tried to set requirements and build monolithically, we would have produced code no better than the previous code because the requirements going in weren't really all that much different than what went into the original program.

This sort of mentality is important to consider on higher levels as well. We need to find what actually improves the development process and focus on doing those things while at the same time refraining from doing things that slow down the process.

How about the ergonomics though? Seems like it would be hard for both people to get a comfortable position in front of the monitor for that long. Seems like it would be ok for a couple of hours but longer than that I've always leveraged a projector type setup

Easier sharing, collaborating, communicating, etc. Message boards, email lists, irc channels, instant messages, etc simply don't cut it anymore and never really were that effective at anything other than starting fights and pissing people off.