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.

About Larry O Brien