Remembering Y2K

As we end a decade, my thoughts go back to January 2000. It seems long ago, yet also seems like yesterday: the rush to convert computer software so that it would work properly as of January 1, 2000. The rumors and truth were hard to decipher and many, in my opinion, just exploited what was not as severe an issue as many believed. Buildings were not going to fall, cars were not going to explode, and the toilets would still function in 2000 as they did in 1999. But I get ahead of myself.

The problem falls on the computer technicians, of which I was one. Yes, the tendency was to blame management for not anticipating the problem, but management must rely on its specialists when such details are vital. It all began with the lowly punch card, the media used in the 50s through the 70s for primary entry of data into computer systems. These cards only allowed 80 characters, so the decision to limit the year to two digits was appropriate.

Unfortunately, once into the computer system, the software to process the data left the year intact at two characters, when the year could then have been expanded to four, e.g., convert 65 to 1965 (or 1975, etc.), as mainframe computers had no 80 character restrictions. (In fact, mainframe computer data was stored on reels of magnetic tape, which was endless in capacity).

Do I oversimplify? Probably, but the solution was readily available. More likely, the computer wasn’t programmed for a four-digit year because we didn’t contemplate that the software would still be in use thirty-plus years later. But that is what happened: the software developed in those early years became the bread-and-butter corporate applications: payroll, billing, inventory and more that addressed cash flow, all being heavily dependent on arithmetic involving dates, such as figuring interest on loans or aging inventory.

However, dates were only part of the problem. That early software was not developed with structured methodologies, but with more of a spaghetti approach, so locating the places in the software where date-related decisions were made was non-trivial, sometimes requiring complete rewrites of systems because earlier programmers took pride in writing indecipherable solutions (yes, I admit being guilty to occasionally doing that).

Yet 99% of all this just affected the corporations, not you or me. I recall much smoke about Microsoft Windows PC software not being able to roll over to the year 2000. And I also remember people spending many $$$ to prevent that problem, even abandoning quality applications for fear of problems on January 1, 2000. Now, it was true that the Windows version in common use then would not switch properly from 12/31/99 to 01/01/00, but the solution was simple: turn the PC off on December 31 and turn it back on after midnight. Ta da! It worked. I’m pleased that I was able to save at least one corporate application by that one simple act.

How would it have affected most of us if there were problems? Incorrect credit card statements and other documents of a similar nature would have been the largest problem. For example, an interest calculation for the time period of December 1999, to January 2000, might easily show interest due for ninety-nine years, not one month. A minor inconvenience for most of us, but the media didn’t miss the opportunity to capitalize on the situation. This newspaper image at is an example of what people were reading, and there were books to advise us, such as this one at . Still, despite my belief that life would go on, I was pleased on January 1, 2000, to see no significant problems. The problem was huge, but that serious business problems were averted is proof of what billions of dollars can do to fix a problem. For me, I was glad to see that chapter end. The funny part is that, if business processes are similar in the year 9999/12/31 (f the world even exists), the same problem will be facing civilization. I hope someone saves a few of those Y2K books to help them.