I'm a software engineer, but I work on machine learning and statistical models, so somebody help me out here on the date processing side.

I don't see one documented case of y2k failure that wasn't rapidly fixed, and/or that caused serious damage. WHAT ? you say, we aren't even IN y2k yet. But much software TODAY:

(a) has to run NOW with dates going forward into 2000 (b) has been test-run into 2000

Don't you all see the xx/00 expiration dates on the food packages ? (I know you all obsessively check food expire dates. Take one to know one.) Those were'nt written by trolls in the back room.

In all cases I've heard about, even ones reported by the alarmists, the problem was fixed, maybe with some fuss, but it is taken care of by just ordinary programmers and others with energy and good will. I know you all will say "but it'll happen ALL AT ONCE". I don't think so, seems like a Gaussian normal distribution of failures, implying that the same fixup process will be repeated ad nauseum throughout '99 and '00

The SF power outage should show us, like I said in another thread about the '89 quake, people do NOT turn into total monsters in a crisis.

(On the other hand I'm getting awful scared by what I'm reading in Japanese on their native info sites about the financial side of this...)

Oh well, just bought some "dragon's breath" special-load 12 ga shells (turns a smooth bore shotgun into a flame thrower, 100 yards, for 3 minute flame-outs, ignites everything it touches. Now, how to apply them to y2k ... )

-RC

-- Runway Cat (runway_cat@hotmail.com), December 08, 1998

Answers

RC: Expiration dates and such have been handled over the years in the normal course of software maintenance without really taxing the finite supply of programming talent. What we are about to undergo, however, starting next month and peaking a year from now, is a major change to essentially all of the world's information infrastructure. This is *on top of* all the other requirements creep (euro, latest tax codes, new features, etc.) that have been demanded by governments, corporations and customers. Most of it will be unfinished, and nearly all of it will be untested, at least in "production" mode.

There is an old adage about estimating a software project's schedule on large, complex systems: double the figure and move to the next higher unit of time (in other words, something that a normal engineer might think will take 1 week can easily take 2 months). Most managers don't do this; they wait for the project deadline to appear on the horizon and then they redraw the line (can't do that this time). They see things as an incremental progression of functionality, a linear increase of SLOC (source lines of code). But complex software does not obey linear dynamics, it increases in complexity exponentially. In fact, we are near the breaking point in complexity in some systems right now, even without the effects of Y2K and the failing global economy. The failed attempts in recent years on billion dollar system upgrades for ATC, IRS, HUD, Social Services programs can attest to this. It's what happens when Information Theory meets Chaos Theory, and we discover that software engineering has been an art all these years, not a science.

The shortage of programmers will become critical next year as hundreds of billions in unspent remediation funds compete for the few remaining skilled workers. The domino effect from crippled computers will multiply as almost every company in every industry in the world is convulsing virtually simultaneously. As the panic sets in, a lot of the software types may decide that they need to take time off to prepare (or bug out), further exacerbating the situation. Now factor in Gary North's breakdown in the division of labor, Paul Milne's social unrest, Infomagic's loss of carrying capacity, and the US government "laying down the law."

Now -- where did you say you got that "dragons breath"?

-- a (a@a.a), December 08, 1998.

The few really spectacular Y2k failures that have leaked through the cracks have involved rolling the clocks ahead and hitting GO. GM and Chrysler had some interesting experiences doing this test earlier this year. I don't think these failures were trivial and I don't believe they have been repaired, either.

Most systems that look ahead have been looking ahead for several years. If not designed for this, they would have failed at various times, e.g., thirty years ago, ten years ago, five years ago etc.

However, there are many systems that look ahead but one year. These systems, if they are faulty, will fail (only now) in groups, e.g., jan 1 1999 (new calendar year and new fiscal year), april 1 (new fiscal year), july 1 (new fiscal year), oct 1 (new fiscal year and new US gov fiscal year), and any other odd-ball fiscal year a company might be using. We may or may not see synchronized failures of various kinds on any or all of these dates depending on the the "visibility" of the failure.

On jan 1 2000, we will see synchronized failures of many, many non-compliant systems that do not look ahead. Unfortunately, we will also be seeing the INITIAL TESTING of great many remediated systems on this date as well. My experience in writing software for Corporate America is that maybe 5-10% of software looks ahead two or more years, 10-20% looks ahead 1 year or less. Another 70-80% only cares what the current date is (but it better know how to handle and format that date or we'll have a huge mess), and the rest doesn't really care.

Of course, it depends on the type of business. Insurance, banks, pensions, and brokerage (i.e., fincance) would have the most look-ahead, everything else has much less. And this is not to imply that finance won't have the same problems as everyone else, they just have more look-ahead code which is probably compliant, at least in the look-head routines in these look-ahead function points.

I doubt many, if any, embedded systems look ahead. So these all have to make the rollover on jan 1 2000, too.

Note that this is all personal opinion and observation -- I have no formal independent studies to back any of this up.

-- Nathan (nospam@all.com), December 08, 1998.

Pretty much what I am seeing and hearing Cat. The failures are coming along slowly - but we can expect several peaks IMHO rather than Gaussian distribution. The peaks should come around the common FY rollover dates - and of course will all involve software troubles rather than hardware problems.

About hardware - have you realized that the 'invisible date' claim for embedded controllers is bogus? If the date is invisible, then it can't be set on startup - so must be running from whatever the default startup date for the controller is. And that means that whenever it rolls over or times out or has whatever kind of dating problem it has - it will not be on 1/1/2000 - because the damn clock will be wrong - probably by many years!

-- Paul Davis (davisp1953@yahoo.com), December 08, 1998.

Paul: the invisible date problem is real, although its severity is not known, and probably not great. I read about it on a tech site and have lost the URL. It only affects systems that have a method of retaining date. The article said that all of the effects would occur after 2000. The clocks would have incorrect dates, lagging by amounts corresponding to times that the system had been down. But that eventually the clocks would rollover. I find it hard to believe also, but remember, we will be seeing a lot of unbelievable things related to computers come 2000.

-- a (a@a.a), December 09, 1998.

Thing is A (AA AAA ? never mind, I am not going there) that there are very few electronic devices that last 20 years - either they burn out or are replaced as periodic maintainence, or are discarded when a new system is designed. Shucks, few factory buildings are still occupied after 20 years. And the default setting for most electronics dates is 1/1/80. So I expect most of the controller problem to come from machines that do display the date - but just can't properly handle the rollover without being reset or replaced - which will cause trouble and confusion - but hopefully not some kind of ultimate disaster scenario - I really doubt it will but do not claim to be a prophet.

-- Paul Davis (davisp1953@yahoo.com), December 09, 1998.