THE YEAR 2000 AS RACKET AND RUSE by Nicholas Zvegintzov

Copyright ) 1996 Nicholas Zvegintzov First published "American Programmer", February 1996

Introduction

One instance of a real problem

More instances of bounded storage

What software engineers do

The Year 2000 as ruse

References

Top Page : Consulting : Publications : References : Events : Profile : Contacts : Vendors : Index : Order Form

Introduction

The Year 2000 problem (years stored by their last two digits will overflow from "99" to "00" when the year passes from 1999 to 2000, causing miscalculations and misunderstandings) is not a huge problem of computer software, nor a unique problem, nor a difficult problem to solve, but it is the focus of a huge and unique racket.

The racket treats the Year 2000 problem as huge, difficult, dangerous, and unique. There are doom-laden articles in the newspapers, expensive conferences, collections of articles such as the one you hold, service offerings by consulting groups, special software tools, internet news pages. This is the Year 2000 racket -- the problem is free, but solutions are for sale.

The Year 2000 problem has three advantages that help to make it a perfect racket.

First, it has a basis in reality. Years stored as two decimal digits will overflow in the year 2000.

Second, it is a software problem -- perhaps the only software problem -- that lay people can easily understand. Many have watched an automobile odometer overflow from 999 to 000; many have seen forms printed with two few spaces for a date; many can see the potential problems. Writers and readers who are deeply ignorant of the nature and functioning of software are equally deeply grateful to find an issue that they can understand. It is unique in its comprehensibility.

Third, its association with the turn of the millennium plays into superstition. The word "millennium", whose base meaning is "a thousand years", is also used to denote "A period of prevailing virtue or great happiness or perfect government or freedom from familiar ills and imperfections of human existence" (Webster's 3rd New International Dictionary). In medieval Europe, as the year 1000 approached, millennial racketeers persuaded gullible and superstitious people to abandon their homes and farms to welcome the coming period of prevailing virtue or great happiness. But this is modern times; this is America; this is computers. Alas, no technology since alchemy has so excited superstition as computers have, a world in which buzzwords such as "client-server" and "object-oriented" are intoned as healing spells, and of which it is often seriously suggested that young children have a better understanding than adults. These are superstitious beliefs.

One instance of a real problem

But the Year 2000 is a real software problem -- say the racketeers.

Yes, it is a real software problem, in fact one that teaches a fundamental lesson. It is an instance of the fundamental engineering problem of software, the collision of the limitless promise of computing with the limitations of the real world. Unfortunately it is not the only instance, nor the most dangerous, nor the most difficult to handle.

The limitless promise of computing rests on a theorem first proved by British mathematician Alan Turing in 1937: Any procedure that can be clearly specified can be carried out by software on a computer, provided that the computer has unbounded storage.

Since procedures have been clearly specified in wide and multiple fields, the scope of software is wide and multiple: as you fly at 37,000 feet, software booked your seat, software took your money, software planned the flight, software navigates the path, software stabilizes the plane, software cooks your meal, software routes your telephone call to your destination, and so on. What do seat assignment, accounting, flight planning, navigation, avionics, cooking, and telephone switching have in common? Just that each can be clearly specified; each can be carried out by software running on a computer.

But none of these procedures runs on a computer with unbounded storage. Our confidence that these procedures can be handled by software rests on Turing's proof, but our confidence meets a real world limitation in Turing's "provided that". Real computers do not have unbounded storage; they have a fixed amount of storage. As the catalogues say, "8 megabytes of memory" (one limit) "Expandable to 20 megabytes" (another limit). And what are these megabytes? They are a bounded array of 1,000,000 bounded 8-bit storage locations -- a mine-field of a million limitations to Turing's theorem.

However big the storage, it is not unbounded. Even if it grows every year, it will never be unbounded. And even a self-healing procedure that can say "I have hit a bound -- give me more storage" is a procedure subject to Turing's "provided that" that can itself fail.

This is where real world limitations collide with software possibility, and where engineering -- the creation of useful structures with limited materials -- meets software.

More instances of bounded storage

The problem of the Year 2000 dates is a single instance of the problem of bounded storage. So is the problem of the Unix date, which will overflow at 03:14:08 on 19 January, 2038 (2**31 seconds after 1 January 1970). So is the problem of The Bank of New York when it lost track of $25 billion of government securities in the middle of the night because its software handled one more transaction than it was ready for. So is the U.S. Government running out of Social Security Numbers or the telephone company running out of area codes. So is many an unrecoverable application error relating to memory management and memory leak (and many more obscure and dangerous failures). So is the timing error in the Patriot missile launcher that let a Scud missile hit the Dhahran Barracks.

Engineering is designed to handle limitations, but in software engineering even more than in physical engineering, the limitations shift. Time goes forward, and the year 1999 gives way to the year 2000. Population increases. Sums of money grow. But most of all, users of software add features to their software.

Computer software gets its name because it is soft -- changeable -- unlike hard physical materials. This softness tempts the users and owners of systems to put more and more features into software. As you fly in the airplane at 37,000 feet, far more of its features are controlled by software than were 10 years ago; 10 years from now, far more again will be controlled.

As complexity increases, as features multiply, as numbers go up, Turing's theorem hits us with its "provided that". Something that worked before ceases to work.

What software engineers do

Software engineers have two job assignments cleanly corresponding to the two terms of Turing's theorem. The first is to add features; the second is to guard against limitations.

The first assignment is to clearly specify procedures so that they can be carried out by software on a computer. This is the public work, the hopeful work, the work that promises the limitless usefulness of computers, the work that engenders superstitious hopes ("A period of prevailing virtue or great happiness or perfect government or freedom from familiar ills and imperfections of human existence").

The second assignment is to ensure that these procedures can be, and continue to be, carried out on bounded computers. This is the hidden work, the cautious work, an engineering work that copes with the limits of the real world, the work that engenders superstitious fears ("The world will come to an end on January 1, 2000").

Dealing with the Year 2000 problem is a simple software task. It is clear when the problem arises (at the end of the century). It is clear what it will do (confuse calculations performed with dates). The places where the problem arises are easy to find in software code (places where dates and times are represented and manipulated, places where fields of two decimal digit are used). The corrective action to be taken is straightforward (substitute a time and date representation with a longer horizon). Solving the Year 2000 problem is an exercise for the software novice.

Most real world software problems are much harder; they are problems in which neither the context, the symptoms, the evidence, or the treatment are so plain. If an organization cannot handle the Year 2000 problem, it is a dangerous organization indeed; avoid it!

The Year 2000 as ruse

Nevertheless software people seem to agree with the Year 2000 racketeers to treat this problem out of all proportion to its real danger. They are flocking to conferences, buying consulting services, bringing in software tools, all to combat the Year 2000 problem as if it was "the" problem of the century, not a simple example of problems that they have to solve now and for ever. Why is this? Do they share the superstitious illusions of lay people?

Probably not. At least, we, who rely on software, hope that they do not.

There is another reason -- the Year 2000 as ruse. In the real world in which resources are committed, it has traditionally been easy to get resources for development of new software, hard to get resources for controlling the software we have.

Conscientious software managers and professionals, whose responsibility it is to understand software and make it work, see the Year 2000 racket as working for them. For once, here is a real world software problem that lay people, particularly higher management, can understand ("The Vice President asked me about it on the golf course"), can relate to, and can support.

The software community goes along with the racket as a ruse. In a world where few understand what software people do or why they need resources, they get resources where they can. If the Year 2000 racket can attract resources that they need -- tools and training and preventive maintenance -- for more important and difficult software problems, they will take the resources where they can as long as the window remains open.

The only drawback of this ruse is that it does nothing to eradicate ignorance. After we survive January 1, 2000, the world will not end, nor will it enter "A period of prevailing virtue or great happiness or perfect government or freedom from familiar ills and imperfections of human existence". Superstition will move on to other targets. Unfortunately the ignorance on which the superstition feeds will remain, and so will the real problems of software.

Still, another opportunity will come in 8000 years, when the four- digit year overflows.

References:

Alan M. Turing. On computable numbers, with an application to the Entscheidungsproblem. Proc. London Math. Soc., Ser. 2-42 (Nov 17, 1937), pp. 230-265.

Brian Boyle. Until the end of time. UNIX Today!, February 5, 1990, pp. 48 ff. (The Unix clock example)

-- (Ladylogic@........), February 18, 2000