Excellence is fragile. Dumb mistakes, in contrast, are more durable than Kevlar. It’s a universal law. For evidence, look no further than Microsoft Outlook.
Try this: Go to July 4th. If Independence Day isn’t already listed as a holiday, enter it as an all day event. Then click Tools/Options, the Calendar Options button, then the Time Zone button. Make sure “Show an additional time zone,” is checked, and set up a different time zone from the one you’re in. Click the Swap Time Zones button followed by Okay until you’re back in Outlook, and guess what: Part of Independence Day occurs on either July 3rd or July 5th, depending on your time zone choice.
Way back when Microsoft first designed Outlook, someone decided it would be clever to treat all-day events and midnight-to-midnight appointments the same way. Every subsequent version has inherited this bonehead design decision, which makes calendar management quite annoying for travelers who schedule events and telephone calls in multiple time zones, and want to show up or dial when they’re supposed to.
But wait. It’s worse! When Palm designed the original Palm Pilot, it ignored time zones altogether. You schedule meetings in local time, change the clock when you change time zones, and that has to do.
For entirely mysterious reasons they designed it this entirely incompatible way, even though they also designed it to synchronize with Outlook. The result? Change time zones in Outlook, the clock on your PDA, synchronize, and your calendar starts to look … wrong. And every subsequent version of the Palm PDA has inherited this bonehead design decision.
You’d think neither Microsoft nor Palm ever figured out that people travel.
I’ve found two PDA-based products that claim to fix the problem. One instructs me to never change the time zone on my PC, only the system clock. And by the way, it’s only reliable if I only enter appointments in my PDA, never in Outlook. No thanks.
The other would be fine if it weren’t for those pesky all-day events, and if it worked. Synchronize a few times and both all-day events and regular appointments act like gerbils — they mysteriously multiply. Make that cockroaches, because sometimes you can’t get rid of them: No matter how many times you delete them they just reappear.
The point of this column isn’t to gripe about Outlook and Palm (well, okay, that’s one point, but there is another, larger one). It’s to encourage you to encourage your managers to encourage everyone who works for you to pay attention to the consequences of their design decisions, because bad design never goes away. Quite the opposite — bad design inevitably creates a cascade of ever-more-fragile workarounds that eventually turns even the finest system into a shambles.
For example: Imagine you start up an on-line clothing store. As part of your systems you implement a customer database. In it you define “customer” as an individual: First name, last name, address and so forth.
After a couple of years you discover that sometimes, more than one customer lives at the same address. You’re selling to households and you never suspected. What to do?
Deadlines are tight and other priorities compete for attention so you take the easy way out — you create a Households table and write a program that sweeps the database once a night, recognizes new households, and populates the Households table accordingly.
Two years later you start selling embroidered clothing to businesses that stock up “trinkets and trash.” Now you also have to handle whole corporations, with multiple contacts, as customers. The pressure hasn’t let up, so you handle this situation much as you handled the Households problem.
The result: Every software change from this point forward has to take these kludges into account, increasing your costs while slowing down your ability to adapt to changing circumstances.
The moral of this story is simple: When you find that some of your design assumptions have changed, in the long run it’s better to adjust the design to your new circumstances than to make the quick fix.
Microsoft’s (and Palm’s) challenge is finding a financial motivation to fix the time zone problem, because it’s hard to see how doing so will sell any more software. Yours is a bit different: While “pay it now or pay it later” is easy for an engineer to understand, pay-it-now dollars are much more tangible than pay-it-later dollars.
Understanding the principle is the easy part. Helping the business make the right decision is a lot harder.