Conrad Weisert
January, 1999
NOTE: This document may be circulated or quoted from freely, as long as credit is given to the author.
The "Year-2000 bug" problem is not only immensely frustrating and potentially expensive, but is also surrounded by a continuing and growing torrent of misinformation in the media. Hardly a week passes when we don't read or hear some outrageously misinformed assertion, about either how the problem came about or about the likely consequences of it.
Here are a few of the myths we keep seeing:
Actually that was never a reason to choose a 2-digit year representation, unless we go back to the days of punched cards, when we were desperate to cram information into fixed 80-position records. Even then, that would justify 2-digit years only for data-entry, never in a permanent master file or a database.
Over the past three decades I have participated in a vast number of discussions of application design and of standards for data representation. I don't recall a single instance where anyone seriously proposed using a 2-digit year to economize on storage, much less got such a proposal accepted. I have also reviewed a number of already completed application or database designs. Some of those did indeed use 2-digit year representations, but in each such case that choice originated in habit or thoughtlessness, not in any analysis of storage costs or other trade-offs.
Not only do the economics of storage technology fail to support that claim, but a six-character (YYMMDD) representation actually consumed more storage than an efficient internal numeric representation that supports all years. I've even seen embedded hyphens or slashes in some stored dates, consuming eight bytes per date field!
(Some writers admit that there was never a storage economy justification, but claim that the CPU time to convert to and from an internal numeric date representation was prohibitive. That claim is equally silly, since the CPU time required to do arithmetic on calendar dates in character form is even greater.)
That might excuse an application developed in 1968, but by the mid 70's we knew full well how hard it was to get rid of an old system that works.
In any case, there was absolutely no trade-off to be made either in hardware or people. The cost of year-2000 compliance in 1985 was zero.
Nonsense! Cobol says nothing at all about date representations, except in the special case of retrieving the current ("system") date. The program designer is free to choose any character or numeric representation. Many organizations that used Cobol managed to avoid the year-2000 crisis by choosing a sensible date representation as their standard.
An article in the financial section of the Chicago Tribune asserted:
"It's as if Congress suddenly levied a 20-billion-dollar tax on American business."Such appalling naivete needs to be challenged.
This is a sensitive issue in many organizations, but there's no avoiding the unpleasant truth that the Y2K problem is almost entirely self-inflicted, caused by particular people in organizations. We're not just talking about a failure to perceive a looming issue, but in many cases, worse, a conscious rejection of the zero-cost solution. I have first-hand knowledge of:
All four of those organizations are now embroiled in 6- or 7-figure urgent compliance projects. One of them even engaged at a high consulting fee the very same now-retired executive who had rejected the standard a decade ago. I have no doubt that hundreds of other organizations are in a similar situation.
It's distressingly common after a reorganization or a decentralization for the new executives to make a point of throwing away standards ("bureaucratic red tape") that had been adopted by the hated previous centralized regime. When an organization adopts a new standard, it may require a justification. Why shouldn't repealing an existing standard require a similar justification, assessing the costs and risks? Why is there seldom any accountability for the consequences of such radical actions?
I wrote a short piece for the Chicago ACM Newsletter last year. Although I shied away from suggesting that we punish the perpetrators, if I were a high-level executive today in a large organization, I would, indeed hold accountable:
The lawyers and the courts will have the final say on this one, but I, for one find that notion offensive for any product bought since the mid 1980's.
Return to IDI home page.