- #1
MartynThomas
- 3
- 15
- TL;DR Summary
- Discussion of the lessons that were not learnt from an extensive and largely successful campaign to resolve the problems caused over decades by using two-digit years in data and software.
Twenty years ago, we were waiting to see whether the billions of dollars and thousands of person years spent finding and correcting the Y2K problem (aka Millennium Bug) had been successful.
To remind you: there were three major problems (and a few minor ones - for full details see the paper referenced later).
In the run-up to Y2K, one of the fixes was "windowing", where two digit
years below 20 (for example) were treated as in the 21st century and
years above 20 were in the 20th. There was some speculation that there
might be problems when the end of the window arrived.
This might just be an example:
https://nakedsecurity.sophos.com/20...ers-should-update-now-to-dodge-y2k-style-bug/
even though the product was written after 2000, if a pre-existing library was used. If it is a Y2K end-of-window problem, there may be similar problems about to appear.
People who weren't involved in solving the Y2K problem seem to think is
wasn't a serious issue. But it was and despite the billions of dollars
spent and the tens of thousands of people who worked to identify and fix
the problems, 15 nuclear reactors shut down on January 1st 2000. I led
the Y2K service line for Deloitte Consulting for a few years and I have
described what really happened. See:
https://s3-eu-west-1.amazonaws.com/...binary/2773/2017-04-04-MartynThomas_Y2K-T.pdf
Many of us who were intensively involved in Y2K projects are angry that our success is seen as evidence that there wasn't a problem. There was a serious threat and it these lessons for us today:
To remind you: there were three major problems (and a few minor ones - for full details see the paper referenced later).
- The use of two-digit years in data, which had been going on for decades and was extremely widespread. Dates in the 21st century would have years that were numerically lower than dates in the 20th century, which would lead to incorrect sorting of dates and incorrect calculations of elapsed periods. For example, food that had use-before dates in 2000 would seem to be decades old already and credit cards and security passed that expired in 2000 or later would seem decades out of date already. The first such failures occurred in the late 1980s but the extent of the problem only became widely recognised in the 1990s.
- Several BIOSs in widespread use failed if the current date was entered as 2000.
- PCs and other devices that were used in process control or automation also failed when processing dates in 2000 or later. (for example, lifts (elevators) that checked their maintenance status would fail once the date for next maintenance crossed the century boundary).
In the run-up to Y2K, one of the fixes was "windowing", where two digit
years below 20 (for example) were treated as in the 21st century and
years above 20 were in the 20th. There was some speculation that there
might be problems when the end of the window arrived.
This might just be an example:
https://nakedsecurity.sophos.com/20...ers-should-update-now-to-dodge-y2k-style-bug/
even though the product was written after 2000, if a pre-existing library was used. If it is a Y2K end-of-window problem, there may be similar problems about to appear.
People who weren't involved in solving the Y2K problem seem to think is
wasn't a serious issue. But it was and despite the billions of dollars
spent and the tens of thousands of people who worked to identify and fix
the problems, 15 nuclear reactors shut down on January 1st 2000. I led
the Y2K service line for Deloitte Consulting for a few years and I have
described what really happened. See:
https://s3-eu-west-1.amazonaws.com/...binary/2773/2017-04-04-MartynThomas_Y2K-T.pdf
Many of us who were intensively involved in Y2K projects are angry that our success is seen as evidence that there wasn't a problem. There was a serious threat and it these lessons for us today:
- Having many seemingly independent systems all vulnerable to a single event can be catastrophic. Yet today, we have much of the economy dependent on a GPS signal that is trivially easy to jam and increasingly easy to spoof. (The signal, on reception, is weaker than thhe thermal noise in the receiver's electronics). We also have software monocultures, so that a fast-spreading malware can destroy many systems very quickly (NotPetya was a good example, but imgine if that had used a zero-day vulnerability instead of one that was already widely patched).
- The Y2K failures that did occur didn't propogate because systems were not then tightly coupled. Today's just-in-time supply chains are much more vulnerable to cascade failures.
- In the 1990s, I asked leading companies how confident they were that they could rebuild their key IT systems from souce code successfully. It turned out that basic software engineering standards were poor. Today, software development still looks more like a craft activity than an engineering discipline, (for example, 60 years after Edsger Dijkstra pointed out that testing can only show the presence of errors, not the absence, companies still rely almost exclusively on testing software rather than reasoning about it, and few companies require the use of strongly-typed languages that would avoid a wide range of programming errors).