The Millenium Project

Home > Comments and Articles > Y2K - Remarkable Coincidences
Bookmark and Share

Alphabetical ListCategoriesCommentariesArchiveAbout the SiteHate MailBook ShopSite Map/Search

Y2K - Remarkable Coincidences

The following article appeared in The Australian newspaper on 6 January, 2000. Some parts of it seemed very familiar to me. By another strange coincidence, the author of the newspaper article (an academic who could be assumed to know better) is a subscriber to a small-circulation magazine which published my speech from November 1999 (publication was in December 1999). I contacted the commissioning editor of The Australian and I was basically told that if I stopped annoying him about it he would forget that I had brought it up and also that I should be careful about claiming breach of copyright because I might be sued.

The bits that attracted my attention are highlighted in the text below. You might like to reread my original presentation after you have read this. Parts of my original article are enclosed in boxes for reference.

I have not asked The Australian or the article "author" for permission to reproduce this here. I would be surprised, however, if they complain about copyright infringement.


My neighbour explains that the crumbs he puts round his house each week keep away the tigers. When challenged with the inescapable fact that there are no tigers in Sydney, he replies: "Precisely!".

Tigers certainly exist and would wreak havoc in suburban Australia, but suppose every Australian had to contribute $700 for the crumbs to be spread about the place, with little say in the matter. Then perhaps we would question the sanity of my neighbour more closely.

An analysis of the Y2K phenomenon leads to the conclusion that computer systems are very complex and that no one is willing to say that any computer program will operate in a particular way given a particular set of inputs.

PB
Unfortunately, writing software is extremely complex and there is no theoretical way to prove that any program (other than the most trivial) does what it is supposed to do in all circumstances.

The fact that something might have happened as dates rolled over from 31/12/1999 to 01/01/2000 caused honest people to say that they simply could not guarantee that any computer would not function aberrantly, and somewhat less scrupulous folk to offer to fix the system for large amounts of cash.

Given the 300 million personal computers in the world (turn in your grave the founder of IBM, who suggested the world would need about five or six) each of which might, say, malfunction once a year, nearly 1 million computers should have suffered a glitch on January 1, 2000. Not because of the Y2K bug, but for the same reasons that another 1 million computers hiccuped on December 31, 1999, and yet another 1 million will fall over today.

PB
... with in excess of 300 million personal computers in the world, it doesn't take a very high natural problem rate to produce very large numbers of problem cases. One problem per year on average (which is very optimistic) gives about a million problems per day, so I predict about 30 million problems in January 2000 which will be blamed on Y2K even though they have nothing to do with it.

I believe that the concern of being sued, rather than aeroplanes falling from the skies or nuclear power plants exploding, was the real driver of the Y2K movement, which in its latter days took over as the millennial cult for 2000. No Second Coming of Christ or advent of aliens for this modern age, but our own Y2K millennium computer bug.

Analysed in these terms, we see that Y2K has many of the attributes of the evil forces conjured by wacky sects.

PB
I had originally thought that the hysterical end of the spectrum was a lot like the superstitious or religious millennialist crowd.

The supposed effects are real - computers can fail just as volcanoes can erupt, spewing death and destruction in their path.

The trigger for such effects is defined (the Second Coming), but the actual mechanism for bad things happening is not so obvious (the wrath of God).

Only a small number of priest-like folk who have been given a sign (a two-day computer course for some) can prevent the destruction, and they are willing to do it for a lot of money.

In biblical terms we have got off quite lightly -- $12 billion is only one-quarter of an Australian gross domestic product tithe. Just as with real millennial motifs, the populace has taken the basic idea and, aided and abetted by the communications of the day (the media), allowed the beast to grow and become the terrible scourge that has caused the stockpiling of toilet rolls and baked beans on a hitherto unprecedented scale.

We can see why a number of systems did not fail. No recipient of a heart pacemaker was turned off on 01/01/00. Why? Because there is no date data of any sort in the electronics of these devices. (In fact, this was a joke made by a worthy of the Australian Computer Society two years ago -- which returned to haunt him in the latter days of 1999.)

PB
I remember starting the pacemaker rumour about two years ago when I told some earnest person that my only Y2K worry was that the software in my pacemaker would decide that too much time had passed since the battery was changed and then turn the thing off. I thought the notion was just too absurd for even the silliest Y2K fanatic to believe, but the person I told it to just nodded. A few weeks ago this came up in a discussion between computer professionals and someone told me that perhaps we should ask an electrical engineer "who might know what he is talking about". I gave him the web addresses of six pacemaker manufacturers who were sick of telling people that pacemakers do not care at all about the year.

Network hubs are not Y2K compliant because they, too, have no datey bits.

PB
One expert reported that a network hub was not compliant and needed to be replaced with one that was. As a hub contains no logic and is just fancy sort of double adapter, one would have to doubt this expert's honesty as well as sanity.

Even systems that do deal in time often could be trivially fixed. Credit cards, with lifetimes of five years, can operate quite happily with two digit expiry years, and systems in which the pattern of days, not the actual year, is important (video recorders, traffic lights) can also easily be made Y2K compliant.

PB
Credit cards with two-digit expiry years - as credit cards are never more than five years old the arithmetic to check dates is pretty simple

Cases where what matters is the pattern of days, not the actual year - traffic light systems, air conditioners, video recorders where using 1972 as the year gives the same pattern of weekend days.

Even the dreaded COBOL computer language has been able to accept four-digit years since 1963.

PB
I don't know how many times I have heard that the Y2K problem is caused by saving space when writing in COBOL, but COBOL has had the capability since 1963 of storing a four-digit year in two character positions.

While computer programs are very complicated, there are ways of writing them so that the structure allows the tracking of data such as dates and times.

PB
There have been techniques around since the 1970s for structuring programs and managing development so that it is possible to know where particular pieces of data are used and you can find, for example, dates and change how they are stored or acted upon.

The Y2K problem was, in my opinion, that the snake-oil salesmen managed to take over a minor but potentially annoying problem and run off with it. The real Y2K disaster was that they would cause more chaos than they averted.

Unfortunately for them and their propaganda, there was no small nuclear meltdown in a former Soviet republic, nor did planes in some Third World country drop from the skies (more than usual). The 1 million computers that were going to fail will have done so and the earth continues its merry way round the sun.

In the end, for computer applications, as for any product facing a known situation (01/01/00), the continued working of the program is a problem for the maker of that program and not me, and no amount of disclaimers and fine print would prevent a bad programmer from reaping his legal rewards should his product fail as a result of negligence. My neighbour has given up the crumbs and is laying a trail of $5 notes. These apparently keep the elephants away too. He has offered me to join his enterprise. As he says: "You can never be too careful when your life is at stake."


All donations gratefully accepted
Please help out with a donation.

Back to The Millenium Project
Email the
Copyright 1999-
Creative Commons