Pair programming review

Maybe I can provide some insight, since I'm seeing a lot of "I've never tried pairing but I bet it sucks" kind of comments:<p>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.<p>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.<p>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!").<p>Code quality is worlds better. Programmers tend to pick the first solution they like and implement it; pairing forces you to justify that decision.<p>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.<p>You back out of dead-ends a <i>lot</i> 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).<p>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.<p>That said, there are a couple people pairing will not work for:<p>Mr. "This will never work." Self-fulfilling prophecy, enough said.<p>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.<p>Bulldozers: Some folks just pick a "solution" and will implement, fight for, and force <i>that solution</i> at all costs, no matter how bad it is.<p>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."<p>In short, pair programming <i>can be</i> 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 <i>all at the same time.</i>

I think managers for agile teams should be forced to "pair program" too every single day, with a forced partner rotation scheme. Then we'll see how long pair programming would survive.<p>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".<p>But to be forced into pair programming with forced rotation scheme every single day year after year is nothing but torture.

<i>Pair programming is an agile software development technique in which two programmers work together at one work station.</i><p>I would add:<p><i>Often employed at consultancies where it allows them to charge twice the rate for half the productivity</i>

I guess it works for training new engineers -- they can learn from each other as well as from experienced folks. After a while though, the outcome will be that one either has the talent and the 'knack' for it, or they don't. Those with talent and skill will outgrow the need for training wheels and structured support.

I've never done development pairing. But I did a project once where I acted as the developer and my partner was a subject matter expert.<p>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.<p>Our release cycles were measured in hours not days and we went from prototype to working-in-a-production-environment in a month.<p>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.<p>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.<p>Along the way, what we discovered is that the fast iterations quickly made us realize that requirements we <i>thought</i> 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.

While I agree with much of the article, one note I find important from my pair programming exercises is that pointing out typos is nit-picking and slows the whole process down. It interrupts the flow of the programmer and doesn't contribute anything useful, since the compiler will point out all typos in due time. (All things in moderation: if it's the sort of typo the compiler won't catch and will cause unexpected behavior, then point it out by all means).<p>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.

Great article. I've never done a formal two weeks pair programming exercise like this. Like most, I've been involved in hours or even day long exercises where the goal is to solve a specific and troublesome problem, but never for regular day to day work.<p>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

I think what programming (or more accurately hacking) really needs is a better way for programmers to communicate while coding.<p>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.

"Pair programming" is probably the only agile practice of which I am not convinced. I'm open to do it, but I don't really know how much productive you become. Also a lot of people seem to think agile is equivalent to "pair programming" and reject the rest of the practices.

We've got quite large desk and good quality screen. So we just zoomed in on font size and that was ok. I would not do it on a projector as after few hours on a projector eyes tend to don't see anything any more.

Can I do it while comfortably sitting in my recliner with my MacBook in my lap? That's how I usually write code..

I've never done pair programming in a professional setting, but every time I've paired on a personal project it's been really awesome. Then again, my pairs were great coders, so I can't comment on what would happen if your pair was terrible.