If you want to get a glimpse of what was the
Y2K Bug craze in 1999 Ullman’s chapter on it is a must.
Millenniums may ask: “What was the Y2K bug?” Well, as one who was actively working in IT
at the time, it basically was the number of seriously heavyweight IT-reliant-
and IT-provider-based organizations running crapped out, moth-eaten, disaster-ready
systems for critical public service and infrastructure functions, systems that
were originally developed for Noah's GPSing around Ararat, beggars belief. The
problem with the earlier Y2K and other system's potential 1970s-based clock
issue and its siblings was and is their potential for cascading. The Y2K bug
did, indeed, bite a lot of systems, but it did not go critical and ignite a
runaway reaction. However, before the event absolutely no-one on the planet
knew for sure whether it would or not.
The real problem was in the
corporate/government sphere where old systems running in-house code needed to
be fixed and/or replaced, although those systems could be running on quite
small hardware platforms, and the risks were real that something serious might
happen, and people needed to be informed so that they could carry out the
necessary checks (even if that meant doing nothing). It's very true that the
vast majority of consumer (and small business) hardware/software applications
were sorted by the natural replacement cycle and by the fact that widespread
adoption of computers at that scale was comparatively recent (by which I mean the
late eighties and nineties). The challenge, as anyone who has done any serious
integration testing on enterprise scale applications knows, is testing all the
different scenarios; the risk of a cascading failure is ever present.
Simulating 'what-if' scenarios against a future
time was particularly hard, since we had to advance the system clocks of many
applications simultaneously (or simulate the impact of that). Where finance
postings were involved (as is typically the case with billing and logistics
systems) that becomes exceptionally difficult to plan and organise. In nearly
20 years of working in one the largest organisations in Portugal, I had
never seen such testing done on such a wide scale. At the time, I certainly didn't condone 'mass
scaremongering' and I was not gleeful that the world mostly acted
professionally to fix the Y2K problem. I'm happy that the risks were assessed
and a conservative precautionary principle was followed. If we couldn't
realistically have tested all the possible failure modes of a future time
flipping things into an unstable state it was safer to find and fix as many of
the bugs as possible well in advance. I think it's sad that unscrupulous businesses
used it as an opportunity to pressurise people to upgrade and replace things
that might safely have been left alone, rather than educating them to do more
research and maybe decide for themselves that they were, in fact, ok. The sad
fact is that for many people IT fulfills Arthur C. Clarke's maxim: "any sufficiently advanced technology is
indistinguisable from magic", and they will always be prone to being
conned.
Will we have another Y2K-craze in 2038? I doubt
I will last until 2038 (or the advent of its analogous problem in other
systems, probably around the same time) but, if I do, I really hope this time
sees a cascading reaction; it will indeed be a pleasure to go out, to adapt Bob
Monkhouse's anecdote, listening peacefully to the screams of a multitude of
hitherto complacent and ill-informed dweebs as their teetering systems crash
and burn around them. I'll rouse myself briefly and LOL: "Ha ha," I'll
go. "Ha ha ha." I'll probably be dead when all the planes fall out of
the sky this time, so no worries…
How can we motivate corporate businesses to
address the 2038 issue? Simple. With threats. Ultimately it is all fixable; I
wouldn't panic right now, though it is time to start worrying about it. And
anyone coding time into 32 bit numbers right now deserves to be forced to use
Windows 3.1 for a month until they promise never to do it again…
NB: A personal note. The Germans calmly
assessed the situation and ported non Y2K compliant IBM COBOL code into Y2K
compliant SAP ABAP code, and launched one of the largest software companies on
Earth. Implementing SAP R/3 to replace old IBM ERP solutions was one of the
main ways that companies world-wide avoided the Y2K problem. I was head of an
IT SAP Systems Administration team at the time, and the only think I had to
worry about was to make sure all the programs developed by humans were
Y2K-Compliant, and that was still a big worry I can tell you. My team spent New
Year’s Eve at the office to make sure everything went according to plan while other teams were in the trenches... I remember my team drinking and eating on New Year's Eve...Wondrous times that won't come back.


