Twenty five years ago today, the world breathed a collective sight of relief when nothing particularly interesting happened. Many days begin with not much interesting happening, but January 1st, 2000 was notable for not being the end of the world.

I'm of course discussing the infamous Y2K bug. We all know the story: many legacy systems were storing dates with two digits- 80 not 1980, and thus were going to fail dramatically when handling 00- is that 1900 or 2000?

Over the past few weeks, various news outlets have been releasing their "25 years later" commentary, and the consensus leans towards this was no big deal, and totally fine. Nothing bad happened, and we all overreacted. There may have been some minor issues, but we all overreacted back then.

So I want to take a moment to go back to the past, and talk about the end of the 90s. Let's go for it.

via GIPHY

It's the End of the World as We Know It

25 years on, it's really hard to capture the vibe at the close of the 90s. We'll focus on the US, because that's the only region I can speak to first hand. The decade had a "it was the best of times, it was the worst of times," aspect to it. The economy was up, lifted in part by a tech bubble which had yet to pop. The AIDS epidemic was still raging (thanks, in part, to the disastrous policies of the Reagan administration). Crime was down. The Columbine Shooting was hitting the national consciousness, but was only a vague hint of the future of mass shootings (and the past, as mass shootings in the US have never actually been rare). The Soviet Union was at this point long dead and buried, and an eternal hegemony of the US seemed to be the "end of history". On the flip side, Eastern Europe was falling apart and there was war in Kosovo. Napster launches, and anti-globalization protests disrupt cities across the country.

Honestly, I feel like Woodstock '99 sorta sums up the last year of the decade. A music festival with a tradition of love and peace is wildly unmanaged and held in a hostile environment and devolves into chaos, violence, and sexual assaults.

With the millennium looming, people were feeling weird. There was a very real sense that the world was coming to an end. Not literally, but the sense of a looming apocalypse of some king was inescapable. It's easy to be the rational one and say, "this is just an arbitrary mark on an arbitrary calendar, it doesn't mean anything", but the mass public and the zeitgeist at the time wasn't feeling rational.

When you add the Y2K bug into the mix, people lost their goddamn minds.

The Vibe of Y2K

We'll talk about the technical challenges of the Y2K bug, but honestly, I think it's less interesting than the vibe.

What people knew was this: computers ran the world, and at midnight on December 31st, 1999, every computer was going to freak out and try and kill us. Don't take my word for it.

Honestly, would anyone have cared if the Backstreet Boys climbed into a bunker in 1999? That feels like the end of their reign as the boy band of the moment. Even Dr. Dre, who is clearly trying to be reasonable, doesn't want to be on a plane that night. Christina Aquilera's mom told her not to use elevators.

Or check this guy, who's less afraid of the technical problem and more "the social" one:

It wasn't all panic, like this long segment from the Cupertino City Council:

And certainly, hero of the site Peter, knew it was boring and dry:

But NYE 1999, people were unplugging all their appliances so the computers in them wouldn't freak out. In the run up, people were selling books to help you prep. Survival guides abounded. Some of them took this as a dire warning about the dangers of global warming and sexuality in media.

The public poorly understood what Y2K meant, but were primed to expect (and prepare for) the worst. From this distance of hindsight, we can see echoes of the panic in the response to the COVID pandemic- a very real problem that people wildly misunderstood and reacted to in all sorts of insane ways.

The Problem

Let's get back to this idea of "some programs represented years with two digits". From the perspective of a modern programmer, this seems weird. It sounds like we were storing dates as stringly typed data, which would be a really silly thing to do.

So I want to discuss the kinds of systems that were impacted and why. Because in the 90s, people thought their PCs might blow up at the changeover, but your desktop computer was never really at any risk. It was legacy mainframe systems- the big iron that ran half the world- that was at risk.

To understand the bug, and why it was hard to fix, we need to spend some time talking about how these systems worked. Well, work, because there are certainly a few still in use.

We're going to focus on COBOL, because I've had the misfortune to work with COBOL systems. Take my examples here as illustrative and not "authoritative*, because there are a lot of different kinds of systems and a lot of different ways these bugs cropped up.

Now, as a modern programmer, when we think about representing numbers, we think about how many bits we dedicate to it. An 8-bit integer holds 256 distinct values.

Mainframe systems used "flat file databases". As the name implied, data was stored in a file- just dumped into that file with minimal organization. A single application may interact with many "flat files"- one holding customers, one holding invoices, and so on. There were no built-in relationships or foreign key constraints here, applications needed to enforce that themselves. On a single mainframe, many programs might interact with the same set of files- the accounts receivable program might interact with invoices, the shipping supervisor would also look at them to plan shipping, an inventory management program would update inventory counts based on that, and so on.

These interactions could get complex on any given system. And those interactions could get more complicated because multiple systems needed to talk to each other- so they'd need data interchange formats (like EDI or ASN.1).

In COBOL, you'd describe your flat files with a "data division" in your program. That data division might look something like this:

01 invoice.
    05 cust-id              PIC X(10).
    05 invoice-date.
        10 invoice-month    PIC 9(2).
        10 invoice-day      PIC 9(2).
        10 invoice-year     PIC 9(2).
    05 cust-name            PIC X(50).
    05 ship-address.
        10 street           PIC X(100).
        10 city             PIC X(50).
        10 state            PIC X(50).
        10 zip              PIC X(5).

This is fairly easy to learn to read. This describes a record type called an "invoice". The 01 is a level- the "invoice" is a top level record. It contains lower level elements, like all those 05s in there.

The invoice contains a cust-id. The cust-id is a "PICture" (a string) of any characters ("X") that is 10 characters long. The invoice-date is made up of the month, day, and year fields. Each of them is a PICture of numeric characters that is 2 characters long.

So it's not truly stringly typed- we know that our invoice date fields are numbers. We store them as characters, but we know they're numbers.

This approach has a few advantages. First, it's very simple. We just mash strings together into a file. Parsing it super fast- I know that I skip 10 characters and I'm looking at an invoice date. I skip 6 more, I'm looking at the customer name. I don't have to scan for delimiters or special symbols (like CSV or a JSON file). I know how long each record is, based on this description, so skipping to the next record is simply skipping a known number of characters.

But there are also obvious problems. This format is fragile. If I want to change the invoice-year to be 4 characters long, or add a field, or anything like that, I can't do that easily. I'd break the file. I'd need to somehow rearrange the data as it's stored, and update every program that touches the file.

Changing a file structure means breaking possibly thousands of lines of code and needing to modify all the data in that file.

But the Space Savings

Now, this fragility is obvious, and the programmers of yesteryear weren't dummies. They knew this. Nobody suddenly woke up in 1986 and said, "boy, these flat files seem like they might be hard to modify in the future". People knew, and they worked around it. A real-world data-division might look more like this:

01 invoice.
    05 cust-id              PIC X(10).
    05 invoice-date.
        10 invoice-month    PIC 9(2).
        10 invoice-day      PIC 9(2).
        10 invoice-year     PIC 9(2).
    05 reserved             PIC X(200).
    05 cust-name            PIC X(50).
    05 ship-address.
        10 street           PIC X(100).
        10 city             PIC X(50).
        10 state            PIC X(50).
        10 zip              PIC X(5).

Adding fields with names like "reserved" allow you to add fields without breaking the file or existing applications. It gives you backwards compatibility- programs that know about the new fields can use them, programs that don't ignore it. Records that don't have good values for those fields would need to be updated- but you can add some reasonable defaults to that.

I bring this up because a common statement about the underlying motivation for using only two digits is to "save space". And I'm not saying that was never true, but in real world cases, it wasn't space that was the concern. We frequently would waste space just to future proof our applications.

So why did they only use two digits? Because nobody thought about the first two digits because we just didn't really use them in the middle of the century. If we said "80", we just knew it meant 1980.

And basically the first time someone used this shorthand, there was someone raising the concern that this would eventually blow up. But that brings us to:

Technology Versus Business

We often hear "no one expected the software to remain in use that long", and I think there's some truth to that. Software, by its very nature, is designed to be easy to change and modify. Even when we make choices that are fragile (flat files, for example) we also look for workarounds to reduce that fragility (adding reserved sections).

And over the past 70 or so years of software development, things have changed a lot. Technology changes. That's basically the core thing it does.

But businesses are inherently conservative institutions. They exist to manage and mitigate risk. That's what a shareholder is- shares are a risk pool, where no one person shoulders the entirety of the risk, but they all take on a little.

And I think this highlights a mismatch between technologists and business people. Technologists want to make things good- we're engineers and want to use the best tools to make the best products. Business people want to make money, and the best way to make money (in the long term) is to minimize risks and costs (and really, risks are just a probabilistic cost).

The Solution

There were a lot of ways to address the Y2K problem. Some systems did change their file formats. Some systems added new fields into the reserved section to cover the first two digits of the year. Some systems used a "windowing" solution- every year greater than 50 was assumed to be 19xx, and every year less than that was assumed to be 20xx. This solution sorta kicked the can down the road, and at some point in the future, we might get a Y2K2: Electric Boogaloo as those systems start failing.

The Apocalypse

Now here's the problem, and this gets us back to those retrospectives which inspired this article.

There were real, technical problems here. No, planes weren't going to fall out of the sky. Nuclear reactors weren't going to melt down. Christina Aguilera was never going to end up trapped in an elevator. But without real, concerted IT efforts, a lot of realistically bad things could have happened- systems we depend on could have stopped functioning. Banks could have been thrown into chaos as they failed to correctly order transactions. Airline booking could have been a total shitshow. There would have been problems costing us billions of dollars in the chaos, and yes, loss of life.

But that's wildly different from the fear-mongering. People, faced with a problem they didn't understand, and a big cultural moment which seemed fraught with possibility, freaked out.

So how did we end up there? I think there were a bunch of factors.

First: uneducated people freak out. Like, that's just the natural state of things. Faced with a problem they don't understand, they are scared. Most people's understanding of computers begins and ends with Angelina Jolie's midriff in Hackers.

Second: there were a lot of people, very serious and reasonable people, who didn't want to do anything. As I pointed out earlier, risk mitigation, for businesses, usually means not doing anything. Y2K posed an unknown risk- yes, things might go wrong, but how much and how bad was hard to determine. So why spend money? Just deal with it when it happens.

And counter to that you had people who saw the threat and wanted to do something about it. The rhetoric got heated- and I think the media picked up on that, and amplified that, which brings us to-

Third: the media is technophobic. I think that's honestly true of the broad public, too, and the media just represents that. This comic about caveman science fiction isn't wrong about our relationship with technology. "Computers are going to kill you" is a better story than "computers are going to require some expensive modifications to keep functioning correctly".

Which brings us back to the original question: did the heroic efforts of nerds prevent disaster, or was the whole thing overblown?

And the answer is: both of these things are true!

Bad things would absolutely have happened absent diligent efforts. But it was never going to be as bad as the media made it sound. And because the problem was complicated and poorly understood, you also had loads of grifters and con-artists and highly paid consultants.

One thing "skeptics" like to point at is that nations which didn't spend a lot of money on Y2K didn't have any problems. My counterpoint is that the places where loads of money was spent are the places where most of the software was written and deployed. I'd also argue that the complexity is not linear- fixing two bad programs which interact with each other is more than twice as hard as fixing one bad program. So more software modules raise the costs.

But even with that, it's also true that grifters made hay. Not all of the massive spending was truly necessary. That's… just life. Wherever money is, grifts follow, and highly paid consultants like to feast even in lean times, and they'll gorge themselves when the money is flowing.

And don't worry, we'll do all this again in the run up to 2038, even though we're honestly way better prepared for the 32-bit timestamps to run out.

In Conclusion

Do you know what I did on NYE 1999? I hung out with friends and queued up Strange Days to align its midnight with our own. Then we had a bunch of caffeine and stayed up for the rest of January 1st because technically, the new day doesn't start until you sleep- thus we helped the world skip January 1st, and singlehandedly saved the world from Y2K. You're welcome.

Now, go watch Strange Days.

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!