[107298] in Cypherpunks
Re: FC: How Y2K doomsayers got it wrong
daemon@ATHENA.MIT.EDU (Bill Stewart)
Sat Jan 9 00:30:24 1999
Date: Fri, 08 Jan 1999 21:19:23 -0800
To: Mok-Kong Shen <mok-kong.shen@stud.uni-muenchen.de>,
cypherpunks@cyberpass.net
From: Bill Stewart <bill.stewart@pobox.com>
In-Reply-To: <3691D6E3.555E4F2D@stud.uni-muenchen.de>
Reply-To: Bill Stewart <bill.stewart@pobox.com>
Five days after the year started using the magic value "99",
a message from Mok-Kong Shen appeared, saying:
>For any firm with data processing personals of solid experience,
>it shouldn't be too late if a Y2K project is started today.
>More than 300 days are still left.
Either the message you posted early last year was delayed by
bad mailer software (:-), or you are incorrect.
Some software began encountering Y2K problems several years ago
(badly-written software using dates in the future),
but the big problems triggered on 1/1/99, and bigger problems
will of course trigger on 1/1/00. Any software using "99"
as a special value for the year can obtain incorrect results
during 1999 -- typical bad behavior is to discard a record
or interpret the record as the last record of a list,
and to fail to output error message when doing so.
This can cause incorrect output, or missing output.
Another big problem that occurred 1/1/99 was in the BIOS software
controlling the clock chips of some recent PCs, including 386,
486, and some older Pentium models.
>Like all software engineering problems it can and will be well solved,
>provided that it is correctly dealt with according to the
>state of the art, with neither panic nor ignorance but prudence
>and resolution.
Unfortunately, this is only true to the extent that engineering,
unlike science, includes making good use of the resources available
to you given constraints on information and skill,
which may not the scientifically optimum use of those resources,
and may not obtain the desired results :-) For instance,
given 24 hours to solve a problem, an engineer can develop a
24-hour-quality solution. This is more complete than a
1-hour solution, and less complete than a 365-day,
and there is some threshhold below which the solution is not good enough.
The state of the art in software engineering, for most of
my 25 years in the business, has included clearly defining
the requirements and documenting anything important;
newer practice recognizes that the requirements and constraints
are seldom all known at the beginning of the process,
and tries various approaches to work around this.
Also, good software engineering practice says that you should
define what good and bad inputs are, and your software should not only
do good things when it gets good input, but should also
not do bad things when it gets bad input - maybe this means
producing an error message, maybe shutting down, maybe skipping a record.
In the case of Y2K re-engineering, this all goes out the window.
Good software doesn't die on 1/1/2000 unless there's a good reason,
and you can read the good documentation and see if it warns you about this.
But bad software doesn't have good documentation, the people who wrote it
left the company years ago, there weren't any clear requirements,
you don't know if there was enough testing to know if it met the
unclear requirements, or if the requirements were any good,
the code is written in JOVIAL or IBM 360/90 assembler,
the punch cards for the source code were thrown away years ago when
the vendor got bought out by that paper recycling company,
not that anybody quite knows why they bought that anyway,
and your staff has been bandaiding the code every year to
work around the copy protection that's looking for the 8-inch floppy,
which is fairly inpressive considering that the only people on
your staff who were around when it was bought were the HR department.
So your first job is to find out what software you have,
and try to guess what is good software or bad software;
if you somehow have only good software, *you* might not need to do
Y2K engineering for very long, so this isn't written for you :-)
Why does Bad Input happen to Good Software?
Lots of reasons, but you can't always tell whether input is bad -
if a date 1/1/00 shows up, that;s a good hint,
but what happens if some people's records just don't show up,
because somebody else's Bad Software stopped at 99?
Is it Somebody Else's Problem? Or is it yours? Can you tell?
But even that's well-bahaved bad input -- does it count as
Bad Input if your computer suddently stops receiving electricity?
yes, good operating systems and good databases fail cleanly,
but what happens if the DNS invalidates everything in its cache
because its clock reset just before the router lost power?
And that's only Good Software...
What does Bad Input do to Bad Software? Since you're grubbing through
undocumented assembler code anyway, can you tell if that two-byte
00 or 99 or FF is a date, or a flag, or the length of an array,
or if you're comparng two of those fields because they're dates
(sometimes fixable by offsetting by some value like 30 mod 100,
which is a really Bad thing to do for array-bounds checking :-)
Even if the stuff used to be C0B0L, it can be hard to decipher
without either the source or documentation, or often even with them.
OK, so you gave up on fixing the Bad Software, and you're just
going to replace it with new stuff. That's probably better,
at least if the new stuff runs on Unix and not Win98,
but one reason it was Bad was because you don't have any requirements.
Should you start over with Business Process Re-Engineering and SAP?
There are some Big N Consulting Firms that strongly recommend you do,
and they'll be happy to charge $2-10K per day to help you.
That's trouble enough for an accounting system, which may be
intimately tied to your Just-In-Time warehouse inventory system,
but what about process control problems.
Now let's take a couple of really ugly examples. Say your system
does something simple like accounting, but you're the
Internal Revenue Service, or a tax software provider,
so the accounting is the US Tax Code, for which the laws alone are
several inches thick of ugly contradictory conditions,
the meaning of which is modified by many feet thick of court decisions,
and was often not well-understood by the CongressCritters who wrote it,
except for the provisions that were deliberately trying to obscure the
recipient of the political favor that was being granted.
That's not too bad - look at Air Traffic Control.....
Thanks!
Bill
Bill Stewart, bill.stewart@pobox.com
PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
