My company has been using IP phones for years. Generally, they work great. There’s just one small problem: if the clock on your phone is wrong, you can’t change it. Apparently, the people who designed the phones decided to rely exclusively on network time protocol (NTP), and removed the settings for changing the date and time. So whenever the phone’s NTP software malfunctions, you end up with a random date and time. Right now, for instance, my phone thinks it’s 1:02 pm on December 11, 2006.

How did the product end up like this? I’m guessing that the engineers thought it would be cool to automate the clock feature, so you never have to set it after a power failure or daylight savings time change. Since the phone automatically sets the time from the NTP server, they thought, why even bother letting the user change it? It will always be right, or so they assumed. But in practice, the process of communicating with the NTP server fails all the time, probably due to unrelated bugs in the phone software. In fact, I’ll bet the engineers never tried synching the phone to any NTP servers outside their own office. So for the rest of us, the clock is always wrong.

Aside from the lack of real-world testing that should have brought this bug to the surface, the designers obviously made another big mistake: they left out the tried-and-true method of just setting the time manually, right from the phone itself. This brings me to my point: it’s great to automate things and free your customers from repetitive tasks. But when doing so, you should strongly consider preserving the “old way” of doing things, just in case. Otherwise, you could be creating enormous headaches if your newfangled automation software happens to fail along the way.