[107330] in Cypherpunks
Re: FC: How Y2K doomsayers got it wrong
daemon@ATHENA.MIT.EDU (Mok-Kong Shen)
Mon Jan 11 03:09:13 1999
Date: Mon, 11 Jan 1999 09:00:06 +0100
From: Mok-Kong Shen <mok-kong.shen@stud.uni-muenchen.de>
To: Bill Stewart <bill.stewart@pobox.com>
CC: cypherpunks@cyberpass.net
Reply-To: Mok-Kong Shen <mok-kong.shen@stud.uni-muenchen.de>
Bill Stewart wrote:
>
> 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.....
I think what you wrote isn't bad. But the problem Y2K has to be
solved just like a person who has a serious illness has to be
cured, isn't it? So the only correct thing is to start a Y2K project
today, if there isn't any yet. There is no need of panic, for
panic doesn't help. What one needs is resolution.
M. K. Shen
