Published in TDAN.com April 2000
The greatly hyped, widely feared transition to Y2K has passed with relatively little consequence. To those who didn’t understand it, and to those who bought the hype and are now stuck with that
generator that they’ve never turned on, and probably never will, it all might seem like it was much ado about nothing – just a bunch of hype, used to scare people, fill news stories, and sell
unnecessary products. It was anything but that, and it is extremely important to look at it retrospectively and make sure we don’t make the same mistakes again.
The “Y2K Bug” was simply this: in order to save storage space on computers, the year portion of dates were often stored in a two digit format (“98”) as opposed to a full four digit format
(“1998”). The programs running in the computer were usually written to interpret “00” to mean 1900, rather than 2000. This meant that if a program did an interest calculation, and ran into an
end date of “00”, it probably had been designed to interpret that to mean “1900”, and would have calculated interest from 1900, not from 2000. This would cause a lot of errors, to be sure. On
the other hand, for the life of me, I cannot imagine that ANYONE would have programmed a computer to launch missiles because it ran into a date of “00”. Another dimension of the problem was data,
and program logic embedded in chips, where it is not terribly visible. It is conceivable that a chip in a machine might have been created such that when it read a date of “00”, it might have
decided the machine hadn’t been maintained since 1900, and therefore should be shut down. This particular possibility led to fears about the power generating and distribution facilities in the
world. So, the fears about the Y2K bug were real, especially the erroneous handling of financial data; but a lot of the fear was totally unrealistic. The main point is this: no one knew what was
going to blow up, because we did such a miserable job of documenting the data which was being stored, and the programs which used it.
Most large companies have vast amounts of stored data, and vast amounts of programming that operates on that data. Most companies literally don’t know what they have! Well, they do, but this
unbelievably intricate and vast documentation is in the heads of the Information Services people (“tribal knowledge”), where it is subject to deterioration, aberration, and is not capable of
being searched rationally. So, most companies, when warned that this “bug” was going to begin to occur, had to literally look through every field in every file, and try to remember which ones
were actually dates, with the year stored as a two-digit representation. Having found all the two-digit dates, they then had to embark on the even more difficult search through programs to see if
they actually read/operated on any of the two-digit dates, and if they did, whether their logic would go awry when Y2K passed. If so, the logic had to be corrected, and in many cases, the date
format as stored had to be changed to a safer four-digit form. The cost of the Y2K search and rescue is estimated at between 200 and 600 BILLION DOLLARS, worldwide. Of that cost, at least
two-thirds to three quarters of the cost was simply “search cost” – plowing through the layouts of files and programs to determine what was at risk; one-third to one-quarter of the cost was spent
correcting the date formats, and reprogramming the at-risk logic.
Interestingly, the Y2K Bug is often blamed in the press on obstreperous programmers, who subversively built this lurking error into all the programs on earth. The true fault lies with management of
our companies, government agencies, and other institutions, whose “just get it done NOW” mentality lead to the whole problem; they were unwilling to pay the relatively minor cost of correctly
documenting what had been built in information systems as it was designed and built, so that it could be properly changed and maintained over time. By analogy, this is like designing and building a
huge, complex building, but throwing away all the blueprints, and relying on the vague, fragmented memory of the construction crew to remember all the important details of how the building was
built. Anytime something needs to be fixed, changed, or improved, the construction crew has to try to remember where those pipes went, or how that circuit was wired. This is the pathetic history of
IS in our companies and government agencies, and this is the root cause of the extraordinary cost of fixing the Y2K Bug. It must be noted that the fact that management in companies and government
understood the horrific possibilities of Y2K if they did not attack the problem aggressively, and the effectiveness of the corrective action that was taken is admirable, and responsible for the
fact that most of us felt no computer consequences whatsoever from the Y2K transition. But, OH THE COST! It was if every dollar we thought we were saving by not documenting what we built had to be
spent to correct for this one problem! And most companies find themselves no better positioned to deal with the next wave of change than they were before the Y2K debacle; just one more horrendous
fire fight. The root problem remains firmly in place.
If there is one, irrefutable lesson to be learned from the Y2K debacle, it is this: THAT WE MUST RIGOROUSLY DOCUMENT THE COMPLEX, INTRICATE INFORMATION ENVIRONMENTS WE BUILD SO THAT THEY MAY BE
REASONABLY CHANGED, MAINTAINED, AND IMPROVED IN THE FUTURE. Today’s typically vast networked computer array in the average company is much more complex and diverse than the relatively simple
single mainframe computer setup of yesteryear; however, the degree of proper documentation of how it is all put together typically hasn’t changed one iota: IT IS STILL TRIBAL KNOWLEDGE! The rate
of change in business and government is accelerating, and that trend will not abate. Further, there are those who declare “Whew! Thank God the Y2K thing is OVER! We won’t have to deal with a mess
like that again until the year 10,000!” No perception could be further from the truth. In addition to the constant stream of small, localize changes which inevitably occur in any business or
public environment, there are a whole series of other BIG changes coming which will have widespread programming side effects tantamount to the Y2K Bug:
- The Social Security Administration will run out of unused Social Security Account Numbers. When this occurs, one or more digits will probably have to be added to the SSN. Today, the SSN is used
for myriad purposes for which it was never intended, to try to identify US citizens. This means that it is stored as data in myriad places, and this means that myriad programs and data files are
going to have to be changed when the format (number of digits) of the number changes. This won’t be as big a change as Y2K, but it will cost the US billions.
- Phone companies are changing the use of area codes, and they will also run out of three digit area codes eventually. Again, the number of places phone numbers are stored, and the numbers of
programs that deal with them is uncountable. Again, not as big as Y2K, but a huge change in terms of numbers of programs and data structures which will have to be changed.
- Sooner or later, the US is going to have to get on board with the metric system used by most of the planet. This, in the US, will be a programming and data change even larger than the Y2K
change.
Companies today keep track of all of their important assets using computers, data bases, and programs to manipulate, analyze, and understand them. They have an employee database so they know who
they employ, what they’re doing, how much they cost, and how they can use those assets to accomplish strategic goals. They have a database about their money: where it is, what status it is in, how
much there is, how much is available, how much is spent/obligated, etc. Remarkably, these same companies have unbelievably complex networked computer arrays, vast amounts of programming, and even
vaster amounts of data, and NO DATABASE TO REPRESENT HOW IT’S ALL PUT TOGETHER. The average company can’t go to a database and ask the simple question: what fields in what files are two-digit
date fields? And which programs use those fields? For a company which is building its information environment correctly and responsibly, this should have been a two-second query to a database, not
a multi-hundred person-year search through every file and every program in the environment!
Please, please make a New Year’s Resolution in your company or government agency right now: we will fully and correctly document every piece of data we’re going to store, every program we’re
going to install and use, which programs use which pieces of data, every piece of hardware we’re going to install and use, how those pieces of hardware are connected, and all the other complex
relationships, attachments, and interactions between them so that we can much more easily and cheaply deal with the inevitable change that is going to happen in our world. Change will occur, and
can’t be prevented; it must be dealt with, but at acceptable cost and effort. If we will keep this resolution, never again shall we go through the horrendously expensive, and preventable “Death
March” Y2K brought us, and we’ll be admirably positioned to deal with the inevitable, and sometimes far-reaching changes that are still coming.
