Thought of the Day - January 24 2022 - Mass Psychosis

This is the fourth in the series concerning the psychological impact of the pandemic.

Learned Helplessness: Thought of the Day - October 5 2021 - Learned Helplessness

Pandemic Shock: Thought of the Day - November 30 2021 - Pandemic Shock Aggression

Abusive Relationships: Thought of the Day - January 14 2022 - Abuse

For this topic, I am not going to talk about the pandemic itself, as this subject might be too emotive to deal with directly. Instead, I am going to talk about another time that I have seen what might be called the phenomenon of mass psychosis occurring, namely Y2K.

For many, Y2K maybe some distant memory. For others, the Millennium Bug may be a new topic, so let me give you a little background. The Y2K issue arose as the folks in Information Technology looked ahead to the coming of the new millennium i.e the Year 2000. Concerns were raised about the viability of a cross-section of legacy computer software (both application programs and hardware microcode) to operate properly into the new millennium. Twenty-five years earlier, it was a common practice to code the calendar year using just the last two digits (skipping the 19). This was to save precious memory space. The programmers at that time never thought that the software they were writing would still be in active use 25 years later - they just needed to implement an operational system given the computer hardware constraints of the time.

At the end of the last century I worked for Alcan, the large multination mining company now owned by Rio Tinto. For us, the main concern centred around the control systems in use at our industrial manufacturing facilities. As it turned out in almost all cases there was no issue, after all, material handling systems do not need to know what year it is. Any reference to time is relative, not absolute. Next, there were the reporting systems. Here a few issues were found, as when rolling over production reports into the new year some may not sort properly if a two-digit year is used - 99 would be a higher year number than 00 so things would get out of sequence.

It had taken a while for the IT and engineering people to convince executive management that this review of key software was needed. For us, it was 1998 before the appropriate time, money and priority were allocated to the task. However, just as we, and our fellows in other organizations, were getting started, Y2K began to take on a life of its own. Stories started appearing in the press. Worst-case scenarios of planes falling from the skies and elevators plummeting to the basement. You see people had now realized they could make money off the back of people's fear, a lot of money, and so they fed the flames. As the general public got "informed" a sort of mass psychosis took over and the feeding frenzy began.

It quickly went from trying to fix a few issues to consulting companies arranging "must attend" seminars, manufacturers convincing company boards to make wholesale replacements of systems, and lawyers demanding cascading letters of "Y2K-readiness" certification from suppliers. The IT folk, who were supposed to be assessing and addressing the subject, were pulled into all kinds of crazy workshops, briefing sessions and status reporting duties. We found ourselves with no time to do the actual work.

No problem. Consulting practices magically sprung up and expanded to provide outsourced solutions. Coming up to the millennium our main preoccupation actually moved from addressing a few legacy software programs to ensuring that all these brand new and hurriedly implemented systems were stable through the year-end - the solution becoming a bigger risk than the initial problem.

I remember sitting in a bunker on the eve of the millennium, reflecting on how crazy this had all become. We had sealed ourselves into the custom-designed global command centre. It contained a plethora of communication devices, an array of remote monitoring systems and a display of the globe showing the new millennium rushing west across the Pacific from the Day-Date line. It was 5:00 in the morning Friday, December 31st local time. Rather than ringing in the New Year, our management teams around the world were to get hourly alerts, some using their brand new Iridium satellite phones - just in case all terrestrial communication services suddenly ceased to function or were overwhelmed by the reporting of Y2K disasters.

The first of our locations to roll over were in Australia. An hour to go and suddenly our engineering location in Brisbane Australia went offline. After half an hour frantically trying to reach the local contacts we found out the site manager, probably after having one-too-many after work, decided at the last minute to power the building down - just in case.

This was the one and only incident reported over the coming hours of high alert. Indeed, although we did not tell our stakeholders, by end of the afternoon the IT folk quietly slipped out of the bunker for beers of our own.

Luckily Y2K had an end date, by the end of January 2000 all was done save "paying the piper". Overspending for Y2K was one of the major contributors to the Dot-Com market crash in Q1 2000. Due to overinflated spending in 1998/1999 at the start of 2000 organizations simply walked away from IT and turned their attention to more important issues. And the consulting business, they turned their attention to the next big thing, assessing whether companies are really getting value for the money invested in information technology!

Unfortunately, lessons were not learned. I don't mean lessons on future-proofing software, I mean lessons on what societal mass psychosis can do.

Unfortunately, unlike Y2K, the pandemic does not have an end date.

Cheers

Cliff