 In the latter years of the 20th century, there was a great deal of concern over how software systems with embedded dates would behave at the turn of the millennium. This became known as the "Y2K problem", sometimes referred to as the "millennium bug". Note 1
There were various ways in which a date in the twenty-second century might cause a problem for a computer program, but the most frequent difficulty arose from the common use of only two digits to encode the year, instead of four. A program would have no trouble with the year 1999 turning over to 2000, but there could be a problem with 99 becoming 00. In the simplest case, "00" might be taken as 1900 instead of 2000. In any event, instead of going up by one each year (96, 97, 98, 99), a two-digit year entry would suddenly appear to go down by 99 (99 → 00).
When I first heard talk of this problem, I didn't think much of it. After all, software is very complicated, and "bugs" (that is, problems of one sort or another) pop up in computer programs all the time. If any problems arose, we would simply fix them.
With a little more thought, however, it became clear that this issue might be of more concern than your average run-of-the-mill software bug. First of all, if a lot of software failures were provoked by the turn of the millennium, they would all occur at once. This could cause much more trouble than routine bugs which turn up one at a time.
Furthermore, the software made by Kronos dealt with keeping track of employees' work time. It was so-called "Time and Attendance" software. As such, it did a great deal of processing of dates, greatly increasing the possibility that something specifically date-related could go wrong.
And by 1998, Kronos had about 85 separate software systems, and made 20 or so different hardware data collection terminals, each itself controlled by microprocessor software. Systems of the same general type had a lot of software in common, but there were also variations in the software in each product. Again, we had a great deal of exposure to the possibility of multiple systems failing at once on January 1, 2000.
Well, actually, that one is a work of fiction, but it gives you some idea of the disaster people seemed to expect this problem to cause (see a few more book covers below, and you can click on each to see a larger version, returning with your browser's "Back" button). Given the sensitivity of Kronos products to any errors involving dates, our customers started pressing us to assure them that when the new millennium arrived, nothing would go wrong.
Kronos formed an internal "Y2K Steering Committee" to address all aspects of the issue, and I was appointed the Engineering representative to that committee. This meant that I was responsible for seeing to it that all our products were properly tested, and that any problems that turned up were fixed before the end of 1999. I also created and controlled the corporate web page devoted to the issue, which publicized Kronos's policies and test results.
Of course, test procedures already existed for every product, since new versions of products came out all the time. The test scripts that we already had were called "regression tests", and they were routinely run on every new version of a product to make sure the added features and improvements hadn't introduced any new bugs. Many of these tests were automated, so they could be run quickly and accurately.
But none of these tests routinely operated the product into the year 2000, so all the scripts had to be augmented to specifically check for year 2000 date problems. And on many of our older products, which were no longer being improved even if they were still being supported, our regression test scripts were seriously out of date. Also, our older scripts usually needed to be manually executed, because they had been developed before Kronos routinely used test automation.
And I should point out that Kronos had systems running under multiple operating systems - they didn't all run under Windows. Some of our older systems ran under DOS, the IBM PC's original "Disk Operating System". And for you techies: we also had systems running on UNIX based computers and on the IBM AS-400. We sold other systems built for Kronos by partners, for which we didn't have direct control of the software. There were also Kronos products that had been derived from our standard products, but which had been customized for particular clients, exposing us to the risk that the custom code had introduced Y2K bugs.
Note the predictions of possible doom and gloom on the cover of the book shown to the right: "Staying Warm", "Coping Without Utilities and Transportation", and so on. Click on the cover (or here) to see a larger image (and click on that image to enlarge it even more). Then return here with your browser's "Back" button. You might also click here to see the back cover, with more dire possibilities: "Your lights won't work and your phone is dead", "Your financial records are completely wiped out", and more!
Of course, any problem generating this much concern brings lawyers in droves. Lawyers started lining up to be the first to bring class action lawsuits against any firm that turned out to have any problems at the turn of the millennium. As I said in a speech on the subject of the Y2K, "The lawyers think that the Year 2000 is the best thing to come along since silicone breast implants. Wouldn't you know the lawyers would make something out of this; hey, 'Same shit, different millennium'." Note 3 So Kronos, like everyone else, started being very careful about what it said and what it wrote. A great many of my meetings in the run-up to the year 2000 were with lawyers.
In essence, what we were saying is that it's impossible to absolutely guarantee that there will be no problems, but we are making a major effort to detect any problems and to make it highly unlikely that there is something that we have missed.
To get an idea of the magnitude of the Kronos test effort, you might click the next link to take a look at our "Year 2000 Readiness Disclosure", as it appeared in a document dated January 15, 1999.
Let me close with the contents of an August 1, 1999 letter I wrote to someone concerned about the impact of the problem (the footnotes were added for this blog entry):
"I received your notes on the Y2K problem. As you know, I've been working on it for my company, Kronos, Incorporated. Our web page is at http://www.kronos.com, and if you click on the "Year 2000" graphic, you can see the informational pages I publish on our test effort. Note 4 I was previously aware of the Special Committee report to the U. S. Senate that most of your clippings came from.
Since this is a one-time event, it is very difficult to guess what will happen, and I think observing the results will be quite interesting. I remember as a young child wondering if I would live to the Year 2000, and deciding I might not, because at the time, the age of 57 seemed very old to me, and I wasn't sure I would make it. Now, of course, I think I'm quite young.
My guess is that there will be no really catastrophic problems, but quite a few small disruptions. The latter will be dealt with in one way or another, as people are really resourceful. There may be a few bankruptcies, mostly of smaller companies. I doubt that there will be widespread power outages, or disruptions in the supply chain lasting more than a couple of days (and these will be scattered). For some companies, for a month or two, it will be "patch, patch, patch". Some of the problems that occur will not be seen until January 3 (the first work day for most people), or when the next payroll is run mid-January, or on February 29 (unlikely), or at the end of the first quarter. We will not be "home free" on January 2nd.
However, these are just guesses, and this is a problem that has never stopped surprising me.
There is a good reason why governmental authorities have a tendency to downplay the problem: I suspect that the most serious problems that occur will be due to the actions the public takes to avoid possible problems. For example, I doubt that there are many parts of the electrical distribution system that are date-dependent; why should there be? Thus, I suspect that it will not be prone to failure by itself. However, because people are worried about electrical failures, quite a few companies intend to shut everything off a bit before midnight. If there are any electrical failures, I suspect they will be due to lots of people turning everything off roughly at once. If we make it through that, what will happen when everyone starts to turn everything back on?
Similarly, the ATM's are likely to run out of cash, because everyone will be doing withdrawals in case the ATM's run out of cash. Gas stations will run dry due to all the people filling their cars in case the gas stations run dry. And so on. As one writer pointed out, if 200 million Americans decide to do anything all at once, there will be problems.
One problem that has been exaggerated by the press is the problem of "embedded chips." The press would have you believe that everything with a microchip in it, such as your car, is a candidate for a Y2K failure. That is nonsense (most reporters are scientific illiterates). Most embedded chips don't deal with the date in any way. Here's a simple test: if you don't have to set the date in a device, then it doesn't know the date, and if it doesn't know the date, then it can't have a Y2K failure. This applies to your car; the engine control microchips don't even know what the date is, so how can they have a problem when the century rolls over? Other devices are discussed in my article on "The Year 2000 at Home", which I've enclosed. Note 5
In industry, there are very few problems that will stop resourceful people from getting their products out the door. If their invoicing systems don't work, people will write invoices by hand, until they can kludge together something to get the computer program working again, perhaps by setting the year back. They'll still send out the goods; to do otherwise would be certain corporate death. If the Post Office's computer stops working, they won't stop selling you stamps. If some smaller power companies crash and bring down the grid, other companies will disconnect, and come back up locally. Companies will revert to manual control where needed. As I noted above, people are very resourceful, and they'll do what it takes.
Of course, the lawyers will do well in the aftermath.
The reason I don't think there will be big problems on February 29th is the lucky fact that the year 2000 is a leap-year. That is, it is not subject to the 100-year exception. Most software uses the simple rule "every fourth year is a leap-year", and fortunately the year 2000 is not an exception to that. And most programmers who know the 100-year exception also know the 400-year exception to the exception. Thus, it takes real stupidity to omit February 29, 2000. Not that some people haven't done it. I've got a paper calendar at work that I copied from the wall at the Massachusetts General Hospital in Boston that is missing February 29, 2000, and all the days after that are off by one. But the MGH appointment computer has it right. Note 6
One problem which is seldom mentioned is the enormous loss of productivity the Y2K problem has caused. I've spent most of my time, for the better part of a year, working on seeing that our products get tested, despite the fact that our products have very few problems (because I designed them to work right in the first place). I was assigned to this because, for various reasons, it is important to have a high-level person directing this area. That's nearly a year during which I haven't been designing products, working on strategy, and so on. The lost opportunity costs have been great, I'm hardly the only person in my company working on this, and it's not over yet.
Well, treat it as something that will be fascinating to observe, and above all, don't panic." The onset of the year 2000 was such a significant event that there is a second blog entry about it, called "Y2K (bis)", which has more detailed information about my role in the Kronos testing effort. This is followed by two entries containing the text of a humorous speech on the subject of Y2K that I gave in 1999 to about 800 listeners at the "Kronos Sales and Service Convention" in St. Louis, Missouri. In those entries, called Y2K speech, part 1 and Y2K speech, part 2, footnotes have been added for non-Kronos readers, to clarify some of the references.
  Note 1: Whence the name "Y2K"? I'm sure it's obvious to computer programmers, but it may not be obvious to everyone. "k" is short for 1000, based on the metric prefix "kilo" (e.g., 1 kilogram = 1,000 grams). Engineers and computer programmers use this abbreviation frequently. They'll refer to someone earning $100,000 per year as having a salary of "$100K" (sometimes read as "one hundred kilobucks"). Hence, since this problem related to the onset of the year 2000, and particularly since it was a computer problem, it was natural to refer to it as the "Year 2K" problem, or to shorten it even further, "Y2K". In fact, there's a small twist to the use of "k" to mean 1,000. Computer memories are addressed in the binary (base-2) number system. Thus, memory sizes are powers of 2 (like 2, 4, 8, 16, ...) and not powers of 10 (like 10, 100, 1000, ...). But 210 (2 to the tenth power) is 1,024, which is pretty close to 1,000. So when specifying the size of a computer memory, "k" represents not 1,000, but rather 1,024. Similarly, a Megabyte of memory (1,000 kbytes) is 1,024 X 1,024 (= 1,048,576) bytes, and a Gigabyte (1,000 Mbytes) is 1,024 X 1,024 X 1,024 (= 1,073,741,824) bytes. Although the use of metric prefixes in this way is discouraged by the international standards committee, it is widespread nonetheless. According to the International System of Units (SI) standard, "k" for "kilo" should be lower case, and "G" for "Giga" upper-case. It's particularly important to observe case when using "M" for "Mega", because a lower-case "m" means "milli", one-thousandth. Thus the difference between 1 ML (a Megaliter = 1,000,000 liters) and 1 mL (a milliliter = 1/1000 liters) is a factor of a billion. But people seem to be sloppy with "k" for "kilo", and often write it upper-case. And that seemed to be particularly true for the "Y2K" problem - it was usually written "Y2K" with an upper-case K. [return to text] Note 2: Transcript of President Clinton's remarks on the Y2K bug from the State of the Union address, January 19, 1999: "We also must be ready for the 21st century, from its very first moment, by solving the so-called "Y2K" computer problem. Now, we had one member of Congress stand up and applaud and we may have about that ratio out there applauding at home in front of their television sets. But remember, this is a big, big problem. And we've been working hard on it. Already we've made sure that the Social Security checks will come on time. And I -- but I want all the folks at home listening to this to know that we need every state and local government, every business, large and small, to work with us to make sure that this Y2K computer bug will be remembered as the last headache of the 20th century, not the first crisis of the 21st." [return to text] Note 3: This speech can be found in the blog entries Y2K speech, part 1 and Y2K speech, part 2. [return to text] Note 4: Although the Kronos web pages still exist, their Y2K information has long since been taken down, of course. [return to text] Note 5: I've been unable to locate a copy of this article. [return to text] Note 6: In the 1500's, it became obvious that the calendar was drifting. By the middle of the century, the longest day of the year was ten days early. Pope Gregory the thirteenth put his astronomers to work on it, and in 1582, a decree (called a papal bull) established what came to be called the "Gregorian calendar", which we still use today. The problem with the earlier "Julian calendar" was that it assumed a year to be exactly 365.25 days long, and hence stuck an extra day into February every fourth year. But in fact, a year is very close to eleven minutes shorter than that. Gregory's fix was to take away one leap day per century, removing the ones in the years evenly divisible by 100 (the new century years). But that takes away too much, so leap years are added back in years evenly divisible by 400 (which meant that 2000 was a leap year). And that's the "Gregorian calendar" leap year rule, that we still use today: a year is a leap year (has 29 days in February) if it's evenly divisible by four, unless it's also evenly divisible by 100, in which case it's not a leap year unless it's also evenly divisible by 400. In order to fix the drift that had already occurred, ten days were dropped from the calendar in 1582. Thus Thursday, October 4, 1582 was followed by Friday, October 15, 1582 (note that the cycle of weekdays was not interrupted). But only four Catholic countries immediately adopted the new calendar, with the rest of the world following along later. Britain and the British Empire (including their new world colonies) adopted the Gregorian calendar in 1752. By then, they needed to correct by 11 days, so Wednesday, September 2, 1752 was followed by Thursday, September 14, 1752. British subjects living at the time, like George Washington, corrected their birthdays by 11 days to be retroactively correct per the new calendar. [return to text]
 |
