Sunday, July 30, 2006

Admitting defeat

My previous attempt to sort out the peeling floorboards in the study didn't work, so I tried again, with planers and sanders and implements of destruction. However, the net result was to make the floor even worse than it was already.

So I bought a rug.

Saturday, July 29, 2006

Under the Black Flag

Time for another Globe trip, this time to see a non-Shakespeare play. The listings warned that "the production features bare flesh and filthy language", which sounded fun.

I was groundlinging for a change, and we managed to get to the very front of the queue. When the doors opened and we scuttled in to pick the best spot, Mike oddly went for a place somewhat to the left of the middle.

He'd been before, so while we waited for the performance to begin, I asked about the bare flesh. "That's why we're not standing under stage centre" he replied. Ah.

Friday, July 28, 2006

A month of users

So, in about a month of having beta testers play with the code, we've gotten through around a hundred enhancements, bugs, tweaks and problems (although only a small fraction of these were raised by our beta users—we found the majority with our own testing). There's maybe another fifty that we'd like to get fixed at some point soon, but overall it's looking pretty good.

Predictably, the vast majority of the changes are in the Visual Basic side of things. Partly, this is because the VB code controls the majority of the user interface, and UI code always has a lot of niggly problems. Mostly, this is because the VB code is built on top of Outlook, which is much harder to deal with—it's not that well-documented or predictable, and the behaviour can vary wildly between different patch levels of Outlook or even between different configurations of the same version.

The downside of this is that I'm going to have to get far more involved with the VB side of things to even out the load….

Thursday, July 27, 2006

Perversely floppy

[reading: Dan Simmons, "Olympos"; recently Ursula Le Guin, "The Wind's Twelve Quarters", Peter Woit, "Not Even Wrong"]

Today's perverse test case: setting up Outlook so that my default folders are stored on a floppy disk. This killed two birds with one stone—checking that our code copes with very slow access to the Outlook data, and also that it copes with running out of disk space. But it was a pain in the neck to set up.

Wednesday, July 12, 2006


The other thing we did today was to pause and triage all of the bugs that have stacked up in the system. There were a bunch of duplicates, and lots of problems that could be downgraded in priority, and I was reminded that this is one of the rare occasions where I disagree with Joel.

Item 5 from the Joel Test talks about whether you fix bugs before writing new code: "at any given time, the highest priority is to eliminate bugs before writing any new code".

This is Simply Wrong.

On any significant codebase, there are whole classes of problems that aren't worth the effort of fixing. Pretty much every bug tracking system has a Priority field which is used to set exactly this dividing line. The triage isn't an exact science, but the division can and should be re-adjusted later depending on customer feedback.

Priority is distinct from severity, which describes the impact on the product or the customer. It's possible to have bugs that are very high-severity but which are still low-priority: for example, a comprehensive system crash that only occurs when the epoch rolls over. Conversely, a glaring typo on the front of the UI would probably be high-priority, low-severity.

I once worked on a product that shipped to customers with hundreds of bugs from our internal testing still open in the database. Three years of real-world use later, the number of bug reports that had come back from the field was in the (low) dozens—and not one was a duplicate of an existing bug from the internal test phases. (Which probably implies that our internal testing was probably more thorough (read: expensive) than it should have been).

DLL Hell is other people

Hmm, that was tedious. I've just spent a couple of hours confirming that an obscure bug was nothing to do with us. It turns out that if you upgrade Outlook 2003 to the very latest level (11.8010.8028 SP2), but you don't upgrade XP from its original version (i.e. no service packs, 5.1.2600 in this case), then Outlook puts up a dialog box complaining about a missing WINHTTP.dll.


Our best guess is that this DLL is needed for the junk email control in Outlook, and that it gets automatically installed with any of the XP Service Packs—and that the Outlook updates just assume that the underlying OS has already been patched.

Of course, to confirm this needed an entire fresh install of Windows XP and Office 2003 on a clean machine….

Friday, July 07, 2006

Spot the difference

Spot the difference: here and here.

Thursday, July 06, 2006

Beta blockers

[reading: Johnson Hart, "Windows System Programming (3rd edn)"]

So the private beta continues apace. There's been a variety of minor problems turning up and getting fixed, but mostly we're focusing on two areas.

Firstly, there's the problem of the Outlook object model guard. It seems that Microsoft responded to a wave of email viruses by releasing a service pack that locked down Outlook; any time that external code attempts to access details about an email, Oulook puts up a dialog asking the user whether this is OK or not. (Our beta user who had to uninstall had this problem: a dialog box coming up on every email you look at is rather annoying.)

Of course, this spells doom for almost every Outlook add-in—there can't be many extensions for an email program that don't need to access details about emails. It looks like the restrictions were relaxed in later versions of Office (which is why we'd not seen it ourselves), but we need to cope either way—which probably means Redemption.

The other problem is the tricky business of tuning our heuristics for real-world data. There are five or six different knobs we can frob to adjust how the tracked information gets summarized and displayed, and different settings suit different people depending on their usage patterns. Ideally we'll find a collection of settings that are good enough for everyone; less ideally, we may end up with an options dialog that allows users to pick settings that work better for them.