The facts of the Y2K bug and why it was nothing like Brexit
Those tasked with fixing the millennium bug reject the idea that it was a load of hysteria over nothing
As the year 1999 drew to a close, stories about the millennium bug started to surface, sparking fears that a catastrophic event would materialise once the calendar moved over to the year 2000.
Doomsday preppers called it the end of the world, where planes would fall from the sky and, in some of the more ambitious news reports, nuclear missiles would launch on their own.
It was a lesson in sensationalist reporting, something that many look back on as a hysteria over absolutely nothing. The reality was that the Y2K bug was a very real problem, something that the IT community was working tirelessly to solve long before the media started to spread doomsday predictions.
Front cover of Time magazine from January 1999 - courtesy of Time.com
Unfortunately, parallels have been recently drawn between the hysteria around the Y2K bug and the UK's impending departure from the European Union. Some leave voters have recently suggested that negative press, and the belief that the decision will ultimately prove to be bad for the UK economy, will prove to be unfounded hysteria.
Speaking on BBC 4's Today programme, Tory MP Sir Bernard Jenkin said: "It's unnecessary and we will look back and wonder what all the fuss was about, a bit like the millennium bug," - mirroring comments made by fellow Conservative MP Jacob Rees Mogg.
Regardless of your position on Brexit, the notion that the Y2K bug was innocuous is not only factually incorrect, it also dismisses the work of those in the IT industry tasked with solving a very real problem.
Simple solutions aren't always the best
Politicians have a responsibility to ensure they have a well-rounded knowledge of the various industries and fields that they may be involved with. While no one expects an MP to know the finer details of Y2K, it's reasonable to expect knowledge of the basics, particularly when you hold an influential position.
For Frances Coppola, a financial writer who worked on many IT systems for banks during the 90s, comparing Brexit to Y2K is tantamount to an irresponsible abuse of public office.
"I think it's quite insulting to the IT community," says Coppola. "I feel that for somebody who wasn't involved in it and doesn't know, but is in a position where what he says will be taken seriously, to come out with something like that, which is not the reality of what we did at the time... it's really quite insulting and I felt it was just wrong to mislead people like that.
"It's also with an ulterior motive because the people saying this are doing so because they are equating the year-2000 with Brexit, that is what is going on. They are saying 'just as the year 2000 bug was all a storm in a teacup, so Brexit is all just a storm in a teacup'. I regard the two as completely unrelated, they are not similar in any way."
Throughout the 60s and the 70s, the computer rose to become an invaluable tool in business; financial companies had started to use them to workout interests rates, many power plants were becoming dependent on IT systems for checking water pressure and radiation levels, and even airports were now using computers to schedule flights.
Unlike today, where systems are built with code written upon code to produce complex software, in the 1960s most systems were based on a single line of code. Storage was also a limited and expensive technology during this time, with a single kilobyte of storage going for as much as $100. Shortcuts were then developed as a result, one of which converted four-digit years into just two, simply scrapping the '19' part of the date field. This was workable in the 20th century, and the belief was that such a format wouldn't be in use 40-years later.
"At the time, I don't think it occurred to anybody that the software and the data would be around at the end of the century and would start causing problems," says Professor Martyn Thomas, an independent consultant and systems engineer. "And, of course, the kind of problems it causes is that dates are used primarily for things like sorting or working out extended periods."
The concern was that the change over to the year 2000 would cause a logical error for computers running the two-digit format, as the year would suddenly switch from 99 to 00. Unfortunately, many also failed to realise that the year 2000 would be a leap year - meaning some Y2K bugs would actually happen before the turn of the century.
"So dates that are early in the new century look as though they are early in the old century and so the sorting goes wrong because 2001 looks like 1901 if you drop the 20 and the 19. If you're trying to do something like calculating when a license expires or when a tin of tuna fish passes its sell-by date, again you run into problems. If you've got the century off, it looks as though the license has already expired or the tin of tuna is already out of date if that end date is now in the new century."
The handover of Hong Kong
The official flag of Hong Kong between 1959 to 1997
Coppola, who has worked on financial IT systems since the 1980s, calls it a "defined problem" that they knew how to solve, far from the complications that the Brexit issue has raised for business and the public.
She argues that if Brexit is to be compared to anything, then it has far more in common with the political headache that was the handover of Hong Kong to China in 1997.
After 155 years of British colonial rule, sovereignty of the territory was handed over to China, a project that involved extensive system changes for most organisations. New legislation, a restructuring of government, and a migration of IT systems were all necessary as part of the deal.
Coppola, who was involved in designing risk management systems during the period, says the extent of the work was completely underestimated by senior management because they thought it could be done in three months time. It actually took nine.
"That is a much more similar situation," says Coppola. "Where you actually don't understand what it is you are trying to do. Whereas the year-2000 bug, we did know. We knew what we were looking for, we knew what the problems were and we knew we could fix them. It was a very limited and bounded situation and that is utterly unlike Brexit.
"People who equate the year-2000, as a fact that it went so smoothly, to Brexit are fundamentally misleading people about the nature of what is going on."
Oldest players were hit the hardest
For Professor Thomas, Y2K should be regarded as a near miss as a great number of systems did fail on the century rollover. Thankfully they weren't as interconnected as first thought and the dreaded cascade effect that engineers were worried about in the 90s, mercifully did not materialise.
The bug resulted in comparatively minor incidents that were largely fixed within hours. Most problems were isolated to temporary failure of IT services, such as card services at the HSBC bank or the US Naval Observatory displaying 1 Jan 19100 on its website.
However, it required a monumental effort to ensure Y2K wasn't a calamity and, in the beginning, the costs were very high. According to Thomas, the cost of scanning and then mediation work was around a dollar per line of code.
"It came down to fractions of a cent towards the end of the century because the tools got very much better and, therefore, it became easier for companies that were late to realise they've got a problem, to catch up," explains Thomas.
"Which is why there wasn't the scale of problems at the end of the century that people had feared would happen - and indeed would have happened had the remediation work not been done."
However, the financial cost of large-scale remediation work varied significantly across the globe. It's estimated that the US spent $150 billion in preparation for the Y2K bug, whereas countries such as South Korea and Italy spent next to nothing, and, like the US, only saw minor incidents.
Many have speculated since that regardless of how much money a country spent to fix the issue, the result was the same - a fuss over nothing.
However, Coppola has a different explanation: "It is the countries that were the front-runners in the computing age that had the greatest remediation costs because the bug was confined largely to legacy systems dating from the 1960s and 1970s."
"By the 1980s, most new software was already Y2K compliant and software enhancements to existing systems were also often Y2K compliant," she adds.
There was also the issue of software developers taking advantage of the sudden urgency, charging exorbitant prices for Y2K consultancy work, which hit those countries with the greatest number of legacy systems the hardest.
"Particularly, those with expertise in early languages such as Assembler, could charge the earth, and they did," explains Coppola. "Humans are humans, after all."
The 2050 bug
Unfortunately, the Y2K bug has yet to be stamped out completely, and for those that have worked to discredit the efforts by the IT community, there will be a chance to see a genuine year-2000 bug in 2050.
Not every line of old code could be completely fixed in the run-up to the millennium, and rather than expand the date field, some were simply tweaked with a 50/50 date split. This new rule meant anything less than 50 would be deemed to have the prefix '20' and would represent the 21st century. Anything 50 and over would have the prefix '19', representing the 20th.
It was a quick fix based on the same mentality that governed code development prior to the year 2000. Unfortunately, this means when 2050 comes around, the date format will once again need to change.
"You'd hope by then that some of this ancient code might be replaced, but don't hold your breath, because it works," says Coppola. "If it works, people don't want to change it. Some of these systems are quite mission-critical these days, they're doing interest calculations for millions of people.
"And you can see why they don't because if it all goes pear-shaped, you've got TSB," adds Coppola, referring to the bank's recent IT migration disaster. "That's an example of how dangerous it can be to change financial computer systems and how angry people can get if it goes wrong."
Managing security risk and compliance in a challenging landscape
How key technology partners grow with your organisationDownload now
Evaluate your order-to-cash process
15 recommended metrics to benchmark your O2C operationsDownload now
AI 360: Hold, fold, or double down?
How AI can benefit your businessDownload now
Getting started with Azure Red Hat OpenShift
A developer’s guide to improving application building and deployment capabilitiesDownload now