When I was studying computer programming in college many years ago, I didn't imagine that our work could impact lives, particularly in a negative way. We've heard reports (mostly true) of death, dying, and destruction as a result of software problems, such as the time a plane flew right into a mountain due to the users not being informed of changes to the software. (For more interesting tidbits, check out the check out this Software Horror Stories page .)
We can never predict what kind of bizarre things will happen as a result of software bugs, but today's news is certainly odd: This weekend daylight savings time ended in many parts of the world (but not in the US yet), and the Apple iPhone's alarm didn't handle it properly. When I travel, I almost always rely on my phone's alarm to get me up at the right time. But apparently a lot of people use their phones every day. And yesterday morning millions of Europeans didn't wake up at the right time thanks to the iPhone bug .
Prior to about--oh, I don't know--1970?, there was an easy answer: Just avoid software if your life depends on it. But that, of course, isn't possible today. Nearly everything we use today runs on software. Just in my house alone, I can think of many things that rely on software: The TV (and the gazillion things hooked up to it), the microwave oven, the regular oven, the clocks, the thermostat controlling both the heater and A/C, the list goes on and on. Pretty much anything that runs on electricity these days has some kind of software inside it. (I don't know if the refrigerator does, but I wouldn't be surprised if there's at least some kind of programmable chip inside it.) When I use these things, I expect them to work. I expect that I can go in the other room without my microwave oven suddenly going into hyper mode and irradiating my cat and dog, turning them into grotesque monsters with superpowers. And when I upload a document to DaniWeb, I expect it to work, and that the software won't inadvertently insert a bunch of offensive words.
I expect software to function, even under extreme circumstances. I once worked as a software engineer for a company that does the billing for many of the world's biggest cell phone providers. We had a sophisticated disaster recovery plan in place to ensure everything functioned correctly, even after a disaster. I even joked: "If a meteor hits the world and 90% of the population is destroyed, don't worry, all will be fine: You'll still get your cell phone bill." (And then I'd mumble, "It's not like we're building dialysis machines here!")
I wonder how many people in Europe missed job interviews or other important meetings. Fortunately, the time change was on Sunday morning, but you never know. Maybe a surgeon scheduled to perform life-saving surgery came racing in late. I hope nobody died as a result. But for programmers, this is certainly a wakeup call (pardon the pun), albeit a late one (pardon the further puns), of just how important our job is and why we must go to great lengths to prevent bugs and fix them as soon as possible. For what it's worth, Apple was apparently aware of this bug, as New Zealand was the first to experience it almost a month ago .
A few years ago I wrote a book called Designing Highly Usable Software (except there was a bug in the title: The publisher insisted the word Usable should be spelled Useable). In the book I talked about many kinds of bugs that are easy to prevent. For example, in the Software Horror Stories site I linked to earlier in this article, there's a mention of a guy whose car insurance tripled when he turned 101, because apparently the software only held two digits, thus reporting the guy's age as 1 instead of 101. (Apparently the system knew that 00 was 100. And I'm also guessing the actuaries calculated that one-year-olds have a high accident rate while driving, thus requiring them to pay three times that of a 100-year-old. But I'm only guessing.) In my book, I explained how that's one bug that's very easy to avoid: Don't use arbitrary limits. In that case, the arbitrary limit is the number of digits in an age. Surly people wouldn't have three digits in their age?
Arbitrary limits are a big source of bugs that are easily preventable. For example, I'm using Microsoft Word, and the programmers could have picked arbitrary limits such as, "Only five documents can be open at any time," or "A single document can have up to 256 paragraphs and no more." Such limits, if a programmer imposes them, usually live in the form of an array, and the programmer typing in an arbitrary number when declaring the array. But with things like dynamically-allocated linked lists, there's no reason to impose such limits. In today's software, we can just create a collection object that can hold as many objects as needed as long as there's enough memory. No arbitrary limits are needed.
I don't know what kind of bug caused the iPhone's alarm to turn on an hour late, but regardless, it was clearly a mistake, and, unfortunately, very likely the result of one individual programmer's coding. (I would hate to be that guy arriving at the Apple headquarters this morning.) The moral, then, is that we need to be extra vigilant in our coding, as we never know how our bugs could impact lives.
