Pair programming at a distance

One of the drawbacks of working by myself is that I can’t usually do pair programming. This is usually offset by the increased concentration and “flow” that comes from being by myself and undisturbed for long periods, but sometimes I just need another pair of eyes to look at my code.

Last Tuesday was one of those times. No sooner had I published my little blog entry on “clans” than I started to hear bug reports that traced back to some ActiveX code I’d written for PC Pitstop. It wasn’t straightforward: two people reported “IE aborted in an unusual manner” errors, but over 8,000 people had run it successfully. I’d missed a rare case.

After looking at the relevant code until my eyes started to cross, I gave Dave Methvin a call. “Dave, do you have a minute? I think that I’m insufficiently paranoid to fix this bug.”

Each in our separate offices in different states, we opened up the same Visual Studio project checked out from our version control repository, and looked at the same code. When either of us saw something we didn’t understand, we’d point the other at the line of code. It was almost like pair programming, but without the physical presence. In some ways it was better, because we each had our own mouse, keyboard, and screen.

“Look at line 129. What happens if that pointer is null?”

“How could it be null? It’s set in line 128.”

“Suppose there were no items in the list. It’s unlikely, but it’s still possible.”

“You’re right. I’ll add an ‘if’ test right there. OK, it compiles and I’ve checked it in: update your copy and have a look.”

We went on like that for about an hour, and convinced ourselves we’d found every possible problem in what was, after all, not very much code. Then I rebuilt the control, ran all my regression tests, and promoted the control to production.

The ending was happy: after that, there were no more reported “IE aborted” errors, even from the people who had reported them before.

Do you have your own ways of collaborating at a distance?