January 31, 2011
The month of January in Sync land was dominated by two things:
- sorting out the aftermath of Sync 1.6 which unfortuantely reshuffled and duplicated a lot of users’ bookmarks,
- finishing up all the work we need to do for Firefox 4
My colleague Richard Newman and I sat down and stared at the bookmark sync code for quite a bit. We identified and fixed a bug introduced in 4.0b8 that caused the reordering problems people had reported. We also made bookmark sync less aggressive about reparenting bookmarks which should alleviate many of the bookmarks-are-moved-to-the-unsorted-folder and bookmarks-are-duplicated issues. These were fixed for Firefox 4.0b10 / Sync 1.6.2. We also identified a bunch of old bugs, particularly related to the restore-from-backup functionality. These are already fixed and will go out in Firefox 4.0b11 / Sync 1.6.3.
Many of those bugs were due to parallel structures that were not synchronized properly, assumptions that certain values would not change, and similar things. This prompted me to quote Phil Karlton’s famous bonmot a couple of times:
There are only two hard things in Computer Science: cache invalidation and naming things.
Apart from a few UI improvements to the Sync preference window and its dialogs, the remaining work for Firefox 4 mostly consistent of making history sync use the new asynchronous bulk API that Shawn Wilsher implemented. This speeds up sync when you’re syncing down a lot of history (e.g. the first sync on a second device) while improving the UI’s responsiveness at the same time.
As a byproduct, we also fixed a long standing problem in Sync: when a particular record could not be added to the local profile, Sync would stop altogether for that engine, leaving all other changes, including any local changes, unsynced.
January 30, 2011
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.