Rupert Goodwins' Diary

Friday 15/7/2005Microsoft hates me, and wants me to fail. Today, we are planning for a company summer event and as part of a teaser campaign to get everyone in the spirit myself and Alex Coby, ZDNet UK's Prince of Production, are putting together an email with attached crossword.

Friday 15/7/2005

Microsoft hates me, and wants me to fail. Today, we are planning for a company summer event and as part of a teaser campaign to get everyone in the spirit myself and Alex Coby, ZDNet UK's Prince of Production, are putting together an email with attached crossword. Alex has produced the crossword as a very nifty PDF, and it all looks top-notch.

There is one problem. It is very bad form to send large files to mailing lists, because email in general and Exchange in particular is mired in a past where messages were kept short due to slow links, feeble processors and limited disk space. Networks, chips and storage have progressed with admirable dispatch, but you wouldn't know it from the way chunky attachments are duplicated when they need not be and chew up quotas where quotas should not be.

After some thought, the PDF is deposited on a shared directory and a link to it provided as an attachment. Even the link is 3k long, which seems curiously full for half a line of text, but that's still better than the three megs of the original file.

The email goes out to the entire company. And the entire company gets it — minus the link, which has been primly excised by our antivirus filter for the sin of being a link. Why, you might ask, did the email system not do this check on the outgoing message and bounce it back for fixing? Why was there no way to ask it to confirm the email was acceptable before sending? Why did it not complain when the link was being emailed back and forth during checking? And why didn't it complain when we found an alternative method of embedding the link in a subsequent email, when the payload was exactly the same?

The reasons are doubtless to be found in the way email is an accretion of features, reactive patches and hangovers from twenty years of reactive evolution and market-led competitive design races. It's as much a nightmare to effectively manage these systems as it is to try and use them for anything remotely interesting, so it's not really a question of applying ever more tweaks to cope with cases like this. There's a good case for radical redesign, creating email systems built from the bottom up for the realities of 2005. We've learned a lot about distributed databases in the past few years, and should be well beyond the idea of an analogue of a paper-based system (:cc and :bcc — I ask you!).

Still, all is now well. We'll know better next time — unless, of course, the system gets invisibly tweaked once more and I am once again goaded beyond endurance.

Gah!