Pair programming is certainly the least adopted of the Extreme Programming practices. Given the overwhelming success of the other practices advocated by Kent Beck in “Extreme Programming Explained”—unit testing, planning from user stories, continuous integration and dramatically shorter release cycles—the failure of pair programming to become a standard is notable.

Lately, my colleague Carlos Lima and I have been experimenting with remote pair programming. Remote pair programming is especially interesting, as more and more teams have at least some developers working remotely. Since I live in Hawaii and Carlos in Brazil, remote development for our clients is a given.

Not to sound immodest, but Carlos and I are both very effective solo developers and there’s no danger that one of us will feel they are “carrying” the other. As a matter of fact, the opposite turns out to be true; one of the immediate frustrations with pair programming is that you’re walking the path differently than you would alone.

We were frustrated by the immaturity of tools specifically designed for remote pairing. We could not find any solutions for using Visual Studio or JetBrains’ IDEs together, and NetBeans appears to have dropped its collaboration features. We used Eclipse’s Saros project for a few days, but ultimately dropped it in the face of stability issues (the only thing worse than working with an unstable environment is working with two of them and endlessly repeating over Skype “Did you get that?” or “Hold on, my system froze.”). We also tried Mozilla’s Bespin, but while it has promise, we didn’t think it was yet a viable choice for actual development.

In the end, we dropped back to “the simplest thing that could possibly work,” and shared a screen with VNC while talking over Skype. VNC is available on all modern operating systems and allows for remote control of the screen and mouse. While it’s not nearly as “cool” as Saros’ or Bespin’s multiple cursors and simultaneous editing, VNC is pretty darn bulletproof.

The biggest problem with VNC was that, for both performance and coordination issues, we ended up using a viewport that was a fraction of our monitors’ capabilities. Once you get used to having three monitors, programming at 1024×768 feels like you’re peering down an arthroscope. While using Saros, on the other hand, we could set up our own IDEs as we liked, jump out to our own Internet browsers to Google for answers, and even briefly pair program while communicating over IM instead of Skype.

In general, though, there’s no question that pair programming is best done while talking to each other. I was actually taken aback by this. Carlos and I know each other’s code, and I thought that pair programming would be more like our code reviews, which tend to sound like “right…right…yeah, I buy it…sure…right…” Instead, we moved much more tentatively, constantly checking (if not debating) minor naming or coding choices.

Perhaps that made our code more consistent, but it definitely slowed down the speed with which we did routine tasks. Over time, I learned to bite my tongue until either the method was finished or there was a definite break in programming. It was worse when I was typing—I never realized that I made so many typos and temporary statements.

There were times when the “passenger” caught errors—generally not serious problems. But there were several times when the “driver” was prevented from heading down a dead end, and in those instances you thought, “OK, there’s a situation where the pair helped productivity.”

In general, though, we pair-programmed for half-day sessions for two weeks and rarely if ever got into a state of flow where we achieved programming productivity comparable to either of us separately. Achieving that flow is one of the great attractions of programming, and the results of those fast-flowing hours are generally what separate the better programmers from the average. Programming without achieving flow is, at best, less than optimal.

On the other hand, pair programming keeps you on task. No e-mail, no sports scores, no impromptu coffee breaks. So even though I don’t think we were programming as fast as we might in the best of circumstances, we were chugging along at a slow but steady rate and producing high-quality code as we went. We initially tried the “Pomodoro” schedule of 5-minute breaks every 25 minutes, but found that to be too intrusive. We adopted alternating between 5- and 10-minute breaks every hour.

We eventually invested two person-weeks worth of time into the effort. Did we achieve the productivity that we would have had working separately? No, but the shortfall was not as great as I expected. Even with significant learning costs trying out different environments and communication tools, we produced about a single person-week of code. I think the code we produced was exceptionally clean and even as we ended the experiment we were more productive every day. If we stuck with it, I have no doubt that we’d get at least in the shooting range of our normal productivity, but with better quality. I just wish there were decent IDE support.

Larry O’Brien is a technology consultant, analyst and writer. Read his blog at www.knowing.net.