Software that sucks #1: Why you should do your testing on the train

This is a new rant series where I moan and exhibit my frustration with using some software that has been designed or tested by monkeys. I'll try as much as I can to be constructive and propose reasonable solutions, but sometimes there's just nothing to do to save software with poor design or engineering.

One more week-end, once more another 03:50 hours train trip. I do like these travel times as I feel I knock down work for this blog the most efficiently when I'm on the train.

One thing I don't have is proper connectivity. I have a Vodafone Mobile Connect ExpressCard for my beloved MacBook Pro, which does ensure a nice and easy 3g+ connection to the Internet wherever I am (how I wish apple would include a UMTS/HSDPA chip in their laptop so I could do without the express card). But you see, while France has a vast network of high speed trains on which they ensure mobile phones work (and Paris even has phone connectivity in the tube!), Shakespeare's land is not as gifted. Reception on the London - Manchester line is dreadful, with a few areas with 3G or 3G+ (if the train is stopped), some areas with GPRS, and a few areas where the signal drops too much for anything to go through. As a result, my card disconnects and reconnects every couple of seconds. And that's where I'll do my strangest assertion to date: If you develop any kind of connected application that may be used on a laptop, plan for your testing to happen on the train.

The regular loss of connection for a short while should be and is supported by the TCP stack to a certain extent. But your application *should not* rely on the connection being there. Separating the use of the data from the reception / emission of the data should be priority number one of application developers, and timeout / crash / retry management should be baked in. Outlook does this with it's offline Exchange mode, that separates the caching and receiving of emails between local and remote store, and the displaying of the local store.

However, Internet Explorer doesn't seem to work the same way. It has trouble with displaying web sites if the TCP connection gets suddenly suspended for a while: after doing a small network trace with ethereal, the data gets received again, but for some reason wininet decides to hang in there for a while and do nothing, even if you start a new tab. Closing and reopening the browser solves the issue.

Where it makes me scream is when it's not software, but drivers that encounter these issues. Like the ExpressCard driver. Has any of the engineers working on this driver ever tried it in low reception areas? Expect crashes, hangs, your mouse blocking for a few seconds. Absolutely dreadful. And all this on Windows Vista of course.