Another perspective on Y2K

Last Updated on July 27, 2018 by Dave Farquhar

Rob O’Hara stumbled across a stash of Y2K survivalist magazines and wrote about it. I wasn’t going to be surprised if there were some minor glitches, but I wasn’t expecting the apocalypse. I withdrew a couple hundred bucks from the bank a few days in advance and filled my bathtub with water the night before, so I would have a supply of money and water to tide me over if some glitch interrupted either of them for a day or two.

In late 1999, a lot of people said I was being reckless. Today, people think I was being excessively paranoid. It’s funny how perspectives change.

In a way I wish Y2K hadn’t been such a non-event, because we do have a Y2038 problem, and I’m afraid the Y2K non-event may cause some people not to take that problem seriously. Part of the reason Y2K was such a non-event was because so many critical systems relied on Unix, which never had a Y2K problem. Unix has a Y2038 problem instead.

Y2K, as Rob mentioned, was largely caused my programmers using two-digit years instead of four. Mainframe programmers in particular did this; they were paid bonuses to write code as efficiently as possible, and this was an easy way to save a couple of bytes. Then those mainframes and that code hung around far longer than anyone ever anticipated, because they worked well enough and they were crazy expensive. So we ended up in a situation where those programmers who were paid huge bonuses to save two bytes in the 1960s, 70s and 80s got paid huge bonuses to spend the 1990s finding those dates and undoing their work. Sometimes it was their own work.

I was pretty confident that those mainframe programmers could go back and fix their work. Had I realized in 1999 that it was often the same programmers, I might have left the money where it was and not filled my tub.

I didn’t worry much about PCs. A PC that didn’t know what to do after 1999 generally wasn’t going to crash; it was just going to write weird dates on files. Besides, Y2K provided a convenient excuse to dispose of PCs that had been in service entirely too long. Some shops drew the line at the 486, disposing of anything older than a 386. Some drew the line at the Pentium, disposing of anything with a 486 or earlier CPU. Running critical systems on Windows NT was still a very new phenomenon in 1999. Four short years earlier, Microsoft announced its intention to build an AOL-like online service and run it on Compaq PCs running Windows NT. Many people in the know wondered if they were going to be able to pull it off. AOL, Compuserve, and all of those other online services ran on mainframes. That was just what you did when you were building something serious.

So, while there were noncompliant PCs and noncompliant PC software, they weren’t running the kinds of things that were going to cause catastrophe if they failed at the stroke of midnight. They were running things that were going to cause headaches once people were back in the office on Jan. 4. (Since Jan. 1 fell on a Saturday, most people got Monday, Jan. 3 off for the holiday.)

It’s been a long time now, so I think, if anything, I was on standby on Jan. 1. I didn’t have to be at work at midnight, but in the event of something unexpected–and the general consensus in our shop at the time was that if something bad did happen, it would be unexpected–I could be called in. I think I was supposed to be reachable that night. So I stayed home. I was a couple of months into this blog by then, but whatever I would have written at the time is lost to the ages now. I didn’t go out of my way to save any of that early content.

I wouldn’t expect Jan. 19, 2038 to cause the apocalypse either, but I expect a lot of glitches. We’re reaching a point where the cheapest, fastest way to build almost anything electronic is to embed a microcontroller in it and do it all in software rather than designing circuits using traditional electronics. Many of these embedded systems today are 8- or 16-bit, but the $35 Raspberry Pi illustrates that it’s entirely possible to build a very small, very inexpensive 32-bit Linux system. In 10 years, 32-bit embeddable Linux systems will be ludicrously cheap, so they’ll be everywhere, and a good number of those systems will still be around and unnoticed come 2038.

So while I don’t expect disaster, I do expect an annoying month. Partly because it’s a real problem and not trivial to solve, partly because the systems that have the problem are widespread and only becoming more so, and while most of the decision makers from Y2K will be retired at that point (or worse), plenty of people old enough to remember Y2K will be around, and remember it as a non-event, and won’t make the necessary connections.