For a generation of us, the Y2K Bug was more than just a joke. We are the ones that can remember what it was like during the days leading up to the turn of the century, how nobody was sure just what to make of this obstacle that the so called “experts” were so certain we’d face. It is now 2009, and there are a generation of you out there now who were probably too young at the time to remember all this. So just what was the Y2K Bug? Sit back and take a moment from reading this article to reflect on all of the computers you use in your everyday life. Aside from the obvious personal computer at home, work, or the public library (otherwise, you wouldn’t be reading this), there are the computers that you use every day without thinking much about them. Perhaps you are a student  enrolled in a large high school or college, and your schedules are all generated electronically.  When you go out to the grocery store, there are machines involved in the transaction of money, from the ATM machine to the cash registers and further extended into the credit card readers. You are constantly surrounded by machines imbedded with microchips to regulate functions-coffee machines, cd players, television, automobiles, hospital equipment, and so called “smart” versions of various other everyday objects. Now imagine that every such computer and computer related component in the world stopped working. What if all of them all over the world where to suddenly cease operations at the exact same time?

The immediate response is to dismiss such an event as impossibility, and while such may be true today, back in the late 90’s, no one was very certain.  How could such a thing happen in the first place? To answer that question, one needs to go back to observe the history of computers and their programming. In the early days of industrial computing, back when a single computer filled an entire room and stored data on magnetic tapes, space in a system’s memory was limited. This space was filled by numericals of data known as bits, representing either a zero or a one. In those days, space was at such a premium that programmers had to cut corners wherever possible in order to make sure that a program had enough memory allocated to perform its basic function.  One of the popular shortcuts was to leave out the leading digits of the date, cutting the year 1983 to 83. This particular piece of programming methodology became a standard over time, and saw continued usage long after the advancement of technology eliminated the need to “scrimp” for memory space. Indeed, because technology was advancing so fast, many programmers assumed that their programs would fall out of use in as little as five years time, so the dates a program recognized was essentially a non-issue.

Unfortunately, the programmers guessed wrong. It was very expensive to continue upgrading all the time, so many companies continued to run on outdated software, even as the use of computers began to spread, and microchips permeated every aspect of our society.  These legacy programs served their jobs well, even though there were newer systems on the market; newer wasn’t always better, especially when you only needed a few of the total functions offered by a particular software package. (IE, how many of you really use Microsoft Word 2007’s built-in translator?) Since such programs only recognized the last two digits in all calculations involving dates, it was believed that the programs would behave unpredictably or simply stop working when the year 1999 rolled over into 2000. In the best scenario, the computer would continue to function but would incorrectly assume the year was 1900 instead of 2000, and provide incorrect results whenever a calculation involving dates was called up.

It may not sound like much of a problem, and indeed, it wasn’t seen as such; at least, not until people began to realize just how many computers in every day society relied on date calculations to perform necessary functions.  The book mentions some examples that occurred even before the year 2000, such as the Tiwai Pit incident in South Island, New Zealand, in which an aluminum smelting plant had their production line suddenly and unexpectedly halt in the middle of production when their computer system failed to account for the leap year on New Year’s 1996. It resulted in more than $1 million in damage when several pot cells overheated, and the same exact problem occurred two hours later at another smelting center in Tasmania. Another anecdotal example of how this could be a problem is given in the form of a story about a microchip in a bank vault. It controls when the bank vault can be open and closed, allowing it to be opened during the working week, but keeping it closed on weekends. For security reasons, such chips are buried inside the vault door.  The people who built the chip, the vault, and the bank, never imagined that the chip would need to be removed in the lifetime of the building, so the chip can only be serviced by removing the door.  But on midnight December 31, 2000, the microchip mistakenly rolls back to January 1st, 1900, which wouldn’t be a problem except that that day fell on a Monday while the same date a century later happens on Saturday. As a result the vault remains unlocked during the weekend but refuses to open later in the workweek. So the bank has to be demolished to ensure that people have access to their deposits. Compounding the problem is that many businesses within the same industry all over the world used the same computer systems, and they all faced the prospect of running into such problems at the same time! Even if only a small percentage of banks had to be demolished, if the disruption occurred in all of them at the exact same time, it would turn the cleanup process into quite a logistical problem.  But that is only the tip of the iceberg. Consider that not only does the vault door of the bank not work, but transactions cannot be recorded, credit cards don’t read, bills are credited for ridiculous charges, and computer systems regulating electrical utilities also glitch and cause widespread brownouts, and more…all at the same time!

The book goes into great detail observing how the effect of Year 2000 errors can “ripple” from one aspect of society into others, turning the problem into one of epic proportions. Considering that the extent of Year 2000 problems hadn’t been guessed at until the mid 90’s, there wasn’t much of a window of time in which to fix these errors, and the computer industry has a long history of not making deadlines or budgets. The authors in the book describe the likely outcome of Y2K failures in various areas of society, focusing on things like government, education, food, and work, and then they go on to extrapolate the likely severity of failures and how long they could possibly take to fix, with varying levels of severity calling for a few days to an entire decade.  It is essentially an exercise in risk management; the purpose of the book is to give you a good idea of how to prepare for a possible Y2K related disaster. Having been written in 1997, it does this from the perspective of authors who have no idea what will actually happen, but realize that the situation could be very serious indeed (the possibility of complete social and governmental collapse is even brought up!)

Of course, you and I have the benefit of a decade’s worth of hindsight. I find it extremely ironic how Y2K would pass with barely a whimper (see Wikipedia for a list of problems that did happen; there are only a few) yet the real disasters would manifest in the September 11th terrorist attacks of 2001, and the Depression we’re going through now. In fact, there are even little hints in the book that foreshadows such events as these. To prepare for Y2K was an undertaking unlike any we had ever seen before. Companies spent thousands, and governments spent millions in an attempt to prepare their systems for the coming millennium. We, as a society were suddenly made very aware of all of the vulnerabilities in our very way of life; the computers that we had all come to take for granted. While Y2K didn’t turn out to be the mega disaster that some people thought it would be, perhaps it is possible that the mentality of risk management better prepared us for the real disasters that did lie ahead? Many of the suggestions this book makes are still relevant, especially considering the dismal economy; which came about in spite of a smooth Y2K transition. It begs the question though-What have we learned from the Year 2000 Problem? And if we didn’t learn anything, what does that say about us?