Was it hype or just good planning? Ten years ago I went to a New Year’s party armed with my cell phone and car keys ready to take off at midnight to help deal with whatever it was that was going to happen. Nothing did. It’s true that we had spent many months checking our clients’ PCs and servers to make sure that they would roll over the millennium properly and even tried tricking a few servers into thinking that it was the year 2000 a little early to see how they would react. It’s also true that many computers and software packages were upgraded to thwart the potential bug that threatened to cripple business in the new year. In the end, however, we still didn’t know if all of that work and money spent was really worth it. I can only speculate why computer designers would not have factored in the year 2000 and how it would affect their designs. Possibly they thought that technology would be so advanced by then that computers based on their algorithms would only be found in museums. It might also have just been an oversight that grew into the proverbial elephant in the room. Looking back I wonder what we as an industry learned from it.
If we roll forward a few years, you may remember a government inflicted change that seemed to have a bigger, albeit less publicised, effect on computers and software. In 2007 a decision was made in much of North America to change the dates that daylight saving time starts and stops. Various government agencies had been studying the potential energy savings since the mid 1970’s so this was also not a big surprise, but again the industry was not prepared. In the case of the Y2K “bug”, it was fairly simple to test hardware, operating systems, and applications to see if they would work. A number of testing tools were available and even when the tools were inconclusive, we could always force clocks ahead to see what happened. With DST things became more complicated because of a number of factors. In Microsoft Windows operating systems, users had the ability to manually turn DST on and off as well as change the time zone that a computer was in. For travelling users the time zone might be changed on a regular basis. With email and calendaring software becoming more prolific we also had to look at interaction between users who may be in different time zones some of whom may not use DST. The email and calendar client and server software had to recognize the correct time zone and know whether DST was on or off. To complicate things further still; with so many computers being used in homes as well as businesses and complicated methods to patch systems, many users would simply change the time on their PCs when they noticed that it was wrong. This also happened on servers when IT staff did not know how to correct it or simply didn’t have the time. I could continue describing the complexities and ongoing issues, but clearly the computer industry had not learned how to plan ahead or chose not to.
A decade has now passed since the Y2K “scare”. The beginning of a new decade seems like a good time to look back at what our experiences have taught us. My job and the main goal of our company is to make computers work. That should mean that the people and companies that rely on them should not have worry about anything beyond using the applications that allow them to do their jobs more effectively. I wonder what I will learn looking back over the next ten years.
Recent Comments