Safe to say this issue will never be resolved
Twenty-five years ago, the world waited for the dawn of a new millennium (a few pedants grumbled that the millennium wouldn’t start until 2001, but no one paid much attention). The excitement of the occasion was tempered by concern, and, in some quarters panic, about the possibility of a massive computer outage resulting from the “Y2K” or “millennium” bug.
The origin story of the bug was that, in the 1970s and 1980s, computer programmers had saved space, or merely effort, by coding years with two digits rather than four. Indeed, the habit was so ingrained that the dominant operating system of the day was called Windows 98, and required some minor fixed to deal with the arrival of the year 2000.
Without such adjustments, it was feared, computer programs would misperceive dates in 2000 as if they were in 1900, producing chaotic errors. The issue had been discussed on the then-nascent Internet for years, mostly in humorous terms. But as the critical date approached, the tone turned to panic, at least in the main English speaking countries.
The catalyst was the realisation that the bug might be found in “embedded systems”, such as the microchips found in virtually every modern device, such as aircraft and lift control system. If they failed, technological society might grind to a halt producing the scenario discussed as ‘“The End Of The World As We Know It” (TEOTWAWKI). This scenario was taken seriously enough to generate an effort to check everything from fax machines to microwave ovens.
It soon became clear, however that most problems with embedded chips could not be fixed without scrapping the devices in which they were embedded. Fortunately, no one had been silly enough to design them to rely critically on knowing the date. Except for a minority of true believers (some of whom welcomed the coming apocalypse) TEOTWAWKI faded from view, and attention was focused on software. However, the level of panic did not decline.
At the other end of the spectrum from the TEOTWAKI panic were a small group, labelled “Pollyannas” (of whom I was one, along with investigative journalist Stuart Fist). The Pollyannas argued that, except for mission-critical systems where exact timing control was essential, there was no reason to devote any more, or less, effort to the Y2K bug than to any of the myriad of bugs that affected computer systems, then and now. The best response, in most cases was “fix on failure”, solving problems as they emerged.
As and computers began making calculations about events in 2000 and beyond, it was widely expected that Y2K bugs would begin to emerge. The Gartner group suggested that around 30 per cent of failures would occur before 20002 As 1999 progressed, the absence of any serious incidents led the Pollyannas to predict that would be a non-event, even for the schools, businesses and entire countries that had done little or nothing to make their systems compliant.
This was, however, a minority position. The dominant view was that, while most large organizations in the English speaking world had fixed the problem in time, the results elsewhere would be dire. Travel advisories were issued telling people to avoid countries like Italy and Russia. Non-essential embassy staff were withdrawn. Widespread small business failures were expected.
When the first day of the millennium arrived without incident, everyone claimed victory. The Pollyannas pointed to the correctness of their predictions. Some of the remaining handful of TEOTWAWKI believers suggested that the system really had collapsed, but that the truth was being kept from us. Supporters of the remediation effort claimed credit for fixing large systems, and suggested that some form of herd immunity had protected those who had failed to take action.
Mostly, however, we were eager to forget the whole business. In Australia, the Senate produced a five-page report, concluding that our $12 billion had been well spent. In the US, where the cost ran to hundreds of billions, there was a 30-page report. This report also claimed success for the remediation program but concluded that “fix on failure” had been the right approach for small businesses.
And, 25 years later, no one much has changed their mind. Those involved in the remediation process still consider it a great success, the Pollyannas point to the lack of any serious evaluation and the public as a whole is confused.
There’s a striking contrast here with climate change. A mountain of scientific research built up over decades, has failed to move governments to vigorous action, even as the costs of inaction become apparent. By contrast, there was almost no serious peer-reviewed research evaluating the seriousness of the the Y2K problem or the costs and benefits of alternative responses.
Rashomon allusions are overused, but they are irresistible in relation to Y2K. For programmers in large organisations, the experience of Y2k remediation was that of a huge effort that fixed plenty of bugs was 100 % effective. For small businesses and schools, another thing to worry about about, but too hard to solve, leading to “fix on failure” when problems emerged. For Pollyannas like me who correctly predicted few critical problems anywhere, vindication, but no credit. For most people, another panic and false alarm.
John Quiggin 
Q: Y2K: Apocalypse averted or pointless panic ?
A: Neither. The truth is somewhere in the middle,
Claim: Safe to say this issue will never be resolved.
Response: Incorrect. The issue was clearly and obviously real for some systems, needed to be fixed and wasn’t always fixed in all systems. Any computer programmer or systems analyst can explain why and the ins and outs.
Here’s a guy who explains why. There were amusing false alarms but also real problems averted and real problems not averted.
https://www.theguardian.com/commentisfree/2019/dec/31/millennium-bug-face-fears-y2k-it-systems
The problem (from my perspective as I actually worked on a Y2K project, as an Indian not a chief) was that were so many minor systems to be checked as well as the major systems. This meant that a 100 systems or modules could be checked and no problem found. The Y2K bug found in the 101st system or module could be trivial or far reaching: an issue which would require further checking and comprehensive testing. It was a tedious business. Real problems were found, though none by me.
I suspect Australia’s welfare systems or significant modules of them would have crashed without the Y2K work or else failed to pay large numbers of recipients. Those problems then may have taken hours or days to correct but probably not longer. No government of the day wants a few million welfare recipients to go unpaid and not know how many days it might take to fix. I reckon the recipients wouldn’t have wanted it either.
Honestly, I don’t consider it an issue to under-estimate. I mean mission critical bugs in large computer systems in general. Sometimes really simple and apparently silly bugs can crash entire systems.
But John, anyone using a real operating system at the time knew that Y2K was a relatively minor issue. The big one is in the year 2038. But perhaps the throwaway society will cure that one.
It was a combination of “not as much was vulnerable as we thought” and “we fixed the worst offenders well in advance”.
I remember filling out a Y2K compliance report for a calculator program in the late 1990’s, which didn’t care what the date was at all. 2 + 2 = 4 even if the computer thinks it is in 1900. Crazy times.
Y2K is what convinced me that disaster preparation is impossible with the modern media. They will write a negative story no matter what you do:
We’re not done with time bugs yet. The “Year 2038 Problem” is coming – when signed 32-bit Unix time wraps around to negative numbers. As an embedded programmer, I am already working to modify the 32-bit embedded systems I work on to extend them to unsigned 32-bit (overflow in 2106) or signed 64-bit (overflow in about 290 billion years). I plan to be dead by then.
The core of the problem is that non-programmers actually think that dates mean something and get very upset when the wrong value is displayed. 99.9999% of programs don’t give a toss – it’s just a value the OS provides to plonk in an event log or in the corner of the screen. If you really need the time, ask a GPS.
Rhys.
Anon (James?),
There were plenty of legacy systems extant in the 1990s that would not have processed dates correctly, without remedial action and testing, as 2000 rolled over. To take your words literally “any one” using a “real operating system” might have been alright with their standalone PC. Any corporation or government department using a legacy mainframe system and software with many interdependencies may have been at considerably more risk, along with their customers, users and other impacted parties.
When dates fail to process correctly, the outcomes can range from merely humorous to trivial, inconvenient, annoying, troublesome, serious, system crashing and potentially locally, regionally or even nationally disastrous. Forming a blanket judgement and a reasoning-to-extremes view that anything that is not catastrophic is trivial is not a valid stance, IMHO. With Y2K the devil really was in the detail.
It is very likely, in my opinion, that some very serious failures were averted. This seems to be the opinion of many IT and systems people involved: you know the ones who actually understand this stuff and worked on big systems.
https://danielbowen.com/2015/08/08/y2k-was-not-a-hoax/
Was Y2K milked by some parties? I am sure it was. Did it prompt beneficial systems upgrades and multiple checks for organisations which had been dragging their feet on long overdue upgrades to their legacy systems? I am sure it did. Was it wholly a hoax and a waste? Certainly not. It prevented costly and very likely critical failures.
The much touted “fix-on-failure” is not always a wise approach. It is definitely a foolish approach where mission critical systems and components are concerned. I am sure the people writing on this blog get regular health checks and keep their houses and vehicles maintained (if they can still afford it in our ever worsening, inflation wracked and supply constrained economy). Yes, you can fix (replace) a light bulb on failure but you don’t fix a veranda or deck on failure; after your guests have been ambulanced to hospital of course. You do regular termite and wood-rot checks, at least where I live. I am sure you wouldn’t consent to being a passenger on an aircraft with a long, obvious metal fatigue crack across the wing. You would not be reassured by the claim, “We fix on failure.”
It almost requires an aphorism:
“To any profession the work of every other profession looks superfluous or at least less vital than their own work.”
“To any profession the work of every other profession looks superfluous or at least less vital than their own work.”
I do feel that John is showing an uncharacteristic lack of self awareness here. Yes there was a panic but underlying it there were real issues. Computers are essential for many parts of life that we don’t even think about.
I was an software engineer in laboratory information systems at the time (ie, late 90s), and we certainly found problems that would have affected companies like QML, who provide pathology services for millions of patients in Queensland. (We discovered other problems too, like we had an absolutely critical fixed-width text file that only allowed 9 digits for the Unix time, and which would have failed around 9/9/2001).
One problem is that these labs are very high volume and the samples are perishable and some tests are urgent. So a failure means not only that the patient doesn’t get the test but also there is a backlog that needs to be cleared urgently. Also, the test instruments are very sophisticated and universally computerised, even back then. A simultaneous failure of all the haematology instruments may have caused serious problems for many patients.
As a local nerd identity back home in Victoria, I was interviewed on TV and I said something to the effect that, I don’t think there will be a problem because most modern systems will be OK, and there are many eyes on it and we were taking it seriously. I think the societal panic was probably politically necessary in order to galvanise the resources to review and fix it.
Uniquerhys I agree with all of this, especially your final four points
James+anonymous: You are confirming my point, not refuting it. From the viewpoint of programmers in big organisations, with mission-critical systems reliant on getting correct dates, Y2K was a big deal and the remediation effort was a success.
From my viewpoint at the time, on the board of a government organization which mainly produced official reports and working papers, and didn’t have any date-critical systems, the recommended response (down to checking whether the microwave ovens were compliant) was massive overkill. I pushed, with some success for a more productive allocation of effort towards general risk management, rather than fixing one big.
From the viewpoint of a small business owner, told that they had to fork out for an (Instant) expert to fix their systems or risk business collapse, it was a hoax.
As you both say (apparently without recognising that it applies to you also) “To any profession the work of every other profession looks superfluous or at least less vital than their own work.” In particular, programmers don’t seem very much worried that the way Y2K was approached, while helpful to their own organisations, caused a lot of wasted time and money for others.
John,
Touché!
There was indeed overkill in the approach at the time. It wasn’t initiated by programmers and systems analysts (or their system support flunkies like me) but by bureaucrats and administrators. Bureaucracies are always going to do that kind of thing. Workers simply need to remember the judicious tick and flick. It’s about knowing what needs to be flicked and what really needs checking. The waste may have been less than some surmise.
I get worried by other types of waste. Like the waste of resources by the mainstream media in their central enterprise of the manufacture of ignorance.
[…] Safe to say this issue will never be resolved Twenty-five years ago, the world waited for the dawn of a new millennium (a few pedants grumbled that the millenni… … Read More […]
I started as a business programmer in the late 80s and that topic not only came up pretty quickly but it was also clear that software developers had been aware of it for a long time. Disappointingly, nothing was done about y2k when doing major overhauls or new programs where it would have made sense.
On the other hand, at the time I never really heard a lot predictions of serious woes. The closest was that small outages across all the worlds organisation’s would add up enough for a noticeable economic hit world wide. That seemed a bit silly to me, but what did I know about the world economy.
As to Y2K panic, I saw no panic. People kept acting the same way so far as I could tell at the time. They caught trains, went to work, did their jobs and enjoyed their weekends, the same as usual. The whole panic claim was a media beat-up. Anyone with any sense knew it was highly unlikely that all the microwaves were going to die. And if they couldn’t heat a lunch in a microwave they knew that wasn’t going to be the end of the world.
As I said above, people in large organisations knew how to handle tick and flick exercises to keep bosses happy. They also knew what was mission critical (as did the more sensible bosses for that matter) and what had date processing in it that could conceivably stuff things like pension runs. The system tests and fixes were done including roll forwards of dates (and roll backs and roll forwards, rinse and repeat) of payment run processing etc. in the test environments.
There was no Y2K panic. Using that terminology buys into the tropes of the media beat-ups at the time. I’d call it a little kerfuffle plus quite a bit of tedious necessary work and tick and flicks on the side, not a panic.
Was there really as much waste as the orthodox economists obsess about? I mean as measured by putting everything into aggregated quantities of the nominal numeraire as they do. Frankly, I am highly sceptical about this.
Let’s talk first about wastes of time (and hence of wages and salary). At that time, public services and many large corporations were probably still somewhat “gold-plated” in terms of staffing and resources, at least back office and support roles. There are good arguments for a degree of “gold-plating” but I won’t go into those now. If there is gold-plating and no real or confected crisis then some people are working below capacity. If a real or confected crisis arises (or a combination of the two like Y2K in praxis), then the “slackers” are mobilised. The wage bill is not changed and real productivity goes up. Where is the waste at the juncture of the crisis?
If some (usually small) businesses are sold a pup, a new whizz-bang system or upgrade that they didn’t need, is this of any great importance? In itself, this is no great departure or no departure at all from standard capitalist operations. People are sold excessive stuff that they don’t need all the time and this highly damaging to the environment and sustainability. Why single out this relatively minor instance of capitalist waste the Y2K “panic” when there are far greater instances to expound on? Planned obsolescence, which got a mention from someone above, is of far greater and continuous impact in terms of waste and environmental damage. But to talk about this is contravene the shibboleths (or myths) of endless cornucopia and endless growth.
As was also mentioned by others above, the high rate of checks, tests, fixes and upgrades to systems probably did repair, renew or replace a lot of faltering legacy systems with positive results: a positive return on expense and effort.
Y2K is a sideshow that happened 24 years ago. Surely media, economists and political economists have bigger fish to fry now in terms of analysis and advocacy? Of course, I have no hopes about the media now (mainstream or social). But I still have hopes about the more intelligent and enlightened economists and political economists. I mean hopes that they will speak up and write up. I have precious little hope that they will be listened to but precious little is not none at all.
Fortunately, the people who work on GPS systems didn’t take your advice: http://catless.ncl.ac.uk/Risks/18/96#subj9 … and the same is true of many other systems that aren’t readily obvious to those outside the world of professional software developers.
There’s lots of Y2K discussion in Risks Digest (moderated by the esteemed Peter Neumann at SRI).
Most computer users didn’t need to do anything more than update their systems, but there will always be unscrupulous people who’ll over-hype a problem to make a quick dollar/pound/yen off the credulous; but there are also plenty of places where it is *known* that systems will fail if nothing is done (the unknown: will the system failures be trivial or disastrous?).
There are also dikes that have been built but no heavy rainfall or storm has occurred to need them. Are those wasted efforts?
Having said that, computer systems (and they are typically complex systems with interactions that rival the complexity of interactions in the real world’s economy) have a nasty habit of showing “fat tail” failure probability distributions, and of being brittle –some large failures cause no significant problems and other “trivial” flaws cause major problems (again, see Risks Digest or Schneier on Security). It’s nice to say that these can be fixed when the fail; but sometimes tracking down the complex interactions can take a long time — I’ve literally spent over a month working with one of the best programmers in the world on isolating and fixing a single subtle flaw that had a major effect on Google’s search results quality.
And it’s not just things like the GPS system … imagine the pain (and cost) of cleaning up the mess (and lawsuits) from mis-calculations of short- vs long-term capital gains taxes, which is a relatively trivial thing to fix, except that it requires tedious reading through millions of lines of COBOL code at every financial institution (and at the various taxation authorities).
Finally, let me quote John Quiggin (from Zombie Economics: “… in environments where surprises are unlikely to be unfavorable, it makes sense to apply a precautionary principle to decision-making.”
Anonymous: You, and some of the others in this thread, should lose the attitude. i was fully au courant with the GPS rollover, and the fact that it went smoothly supported the Pollyanna case. I put this on the record in 1999
https://www.dropbox.com/scl/fi/g9ota4o9b81bs1joykbsm/Millennium9908.html?rlkey=984tv846rk9h3et4fmctns6ma&dl=0
We both agree that it was important to fix things like GPS systems.
The problems come when you make claims like the one about capital gains taxes. Calculations of this kind go wrong all the time for all kinds of reasons, and are mostly fixed on failure. “Spreadsheet error” is a standard excuse for mistakes along with “the email went to junk”Spending vast amounts to eliminate one of a vast number of possible bugs in this kind of software was a mistake.