Peter Coffee: Forbodings about Y2K weekend

International Y2K problems won't be The End Of The World As We Know It (TEOTWAWKI, pronounced "Tee-oh-twau-kee"), but on this first day of Winter 1999, I don't find this a comforting assessment, and I don't intend that you should either.

I expect to watch the world endure the first two weeks of the year 2000 the way I get through a bad case of the 'flu. While knowing, in an abstract way, that I'll get better in a week or two, I still find myself wondering why I should think so. January could bring us some most unpleasant days.

I began my exploration of Y2K several years ago, when a colleague at COBOL toolmaker Micro Focus (now part of Merant International Ltd.) pointed out that there were only a thousand working days to go before Y'00. During the next few years, I thought of Y2K as a technical problem -- pervasive but not overwhelming.

I changed my view during the first three months of this year, when I had the opportunity to visit dozens of enterprise sites and government agencies in the Midwest through the co-operation of PC Week Corporate Partner contacts. In many hours of interviews, I came to perceive Y2K as a project management problem, with the sheer size of the task being successfully addressed by effective education and diligent effort.

"We would have crashed and burned," said information systems vice president Jack Steinman at Aurora Health Care in Milwaukee, but a $20 million effort had Steinman feeling well prepared.

Even in those stories that we wrote in the first half of this year, there were whispers of a third and much less tidy aspect of Y2K. The major uncertainty, observed infrastructure providers such as Alliant Energy vice president Pamela Wegner in Madison, Wisconsin, is "abnormal behaviour" -- not of systems, but of users.

All we have to do is run the numbers to realise that a little bit of worry, multiplied by a few hundred million people, quickly turns into a genuine problem.

For example, suppose that during the last two days of 1999, we all decide to fill our automobiles' gas tanks. Let's estimate, if I may, that the typical driver usually fills up at around three-quarters empty, meaning that the average gas tank is normally three-eighths short of full. If the typical tank holds, say, 16 gallons, then we might have about 100 million drivers each pumping about six gallons more than they normally would during the last two days of the year.

An extra 600 million gallons over a two-day period represents about a 75 percent surge above the normal amount of gasoline that's being trucked around the country on a routine basis to keep gas stations' tanks topped up. This is precisely the sort of thing that led to gas lines in the '70s, or that emptied the storage tanks at roughly half of the gas stations in the Southeast that were in the path of the recent Hurricane Floyd.

I'll remind you that the "landfall" date of Y2K, unlike Hurricane Floyd's, is precisely known in advance, which should make for an even sharper surge in demand that leaves even less time for providers to adapt. Y2K readiness outside the U.S is even more subject to overload and breakdown of supply lines and services.

I shouldn't suggest that the only remaining Y2K problems are outside the domain of information systems. Historically, progress reports on major software projects are notoriously optimistic, with "on-schedule" estimates turning almost overnight into major delays or abandonment during what was supposed to be the last 10 percent of an effort.

When did we suddenly start to believe IT progress reports, especially when people know that slipping the completion date is not an option?

In some cases, "completion" of Y2K preparations is being achieved by moving the finish line. The goal of finding and fixing problems before they strike has been changed, in some organizations, to a plan of staffing command centers that swat the bugs as they appear -- not quite the same thing at all, and perhaps further inflating the "Y2K ready" statistics.

Even Y2K-scrutinized systems may still contain subtle bugs, estimated by some professional analysts at tens of problems per million lines of code. Software maintenance data from the last 30 years suggests that roughly seven new bugs are introduced for every 100 fixed, according to Capers Jones of Massachusetts-based Software Productivity Research Inc. -- is there some reason to think that Y2K efforts have been less frantic than normal maintenance projects?

I take no joy in being such a Grim Reaper, or in being invited as the "doomsayer" guest for the December 21 taping of ZDTV's "Silicon Spin." After investing the equivalent of about two full months of 1999 in trying to keep Y2K under control, I wish I had something more encouraging to say than "Be careful, be prepared and stay close to home with the people who matter most."

But maybe that's just good advice for any holiday season, Y2K or not.