As we’re getting closer to shipping Firefox 4, less of us have any blockers to work on while the pressure increases on the few people that do. Here are some thoughts and experiences on how to level that.
This past month we picked up a few blockers in Sync that had people’s bookmarks duplicated and reordered. An embarrassing and unfortunate scenario, especially since it was hard to reproduce and our unit tests were all passing, of course. We had gotten reports of duplicated bookmarks in the past. So while we had recently made some changes to bookmark sync that may have made situation worse, it certainly looked an old lurking bug.
After two days of staring at the code, writing tests that passed and getting nowhere, I asked my colleague Richard Newman to help me out. In previous projects I’ve had extremely good experiences with pair programming. In this technique, two developers sit down over one machine and one text editor. The “navigator” dictates the general direction while the “driver” writes the actual code. Developing code this way has a lot of advantages:
- Two sets of eyes see more than one. Simple mistakes that can slow an individual developer down, such as typos, off-by-one errors, etc. happen less.
- Code is reviewed before it’s checked in. Granted, we already do that at Mozilla.
- Code is reviewed instantly. Less developer and reviewer time is wasted with an asynchronous review cycle and less time has to be spent explaining why a particular change was made this or that way.
However, Richard works remotely, nearly a thousand miles away, although fortunately he’s in the same timezone. As it turns out, pair programming over a distance works great when you have the right tools. Here’s what we did:
- We both had hands-free phones available, so we got on the phone and started walking through the code together.
- As we bounced ideas off each other, we collected our findings in an Etherpad. This allowed us to write down our ideas in a structured manner, while allowing the other one to reorder and restructure them as we filed bugs.
- On some of those bugs, we paired up in the traditional pair-programming sense. To compensate the lack of a common screen to stare at, we used a shared
GNU screensession where I brought up an instance of emacs so that we could take turns in “driving.”
We ended up doing this this for three whole afternoons. We found potential culprits, filed bugs and fixed a bunch. The experience very much reminded me of on-site pair programming. I suggest you try it some time, be it with a colleague who’s remote or not. You’ll feel extremely productive even if you’re not writing a single line of code yourself. Not only that, you’ll end the session with a much better understanding of what the code does (instant r+!).
Let’s kill those blockers dead.
