For fair use and educational purposes We still haven't reached the final chapter of Y2K

By William Ulrich 01/24/2000 Many people believe the Y2K storm passed with few glitches. This has caused people from all walks of life to think the problem was overblown. Others, specifically those charged with fixing Y2K and paying for those fixes, believe we beat the bug into submission. While the media are playing out these two theories, it's too soon to say if either is correct. Y2K is too insidious a problem for us to have a complete picture now.

First, remember that since Jan. 1, we've seen numerous Y2K problems emerge. Systems failed at nuclear power plants in Japan, Spain, the U.S. and elsewhere. Failed credit-card software rebilled accounts on a daily basis for a single charge. The Federal Reserve Bank of Chicago reported problems in transferring $700,000 in tax payments from customers of 60 financial institutions. The FDA reported 24 medical device failures. Heating systems went out in schools, and food stamp deliveries and Medicare payments were late. The Defense Department lost track of a spy satellite, prison terms were miscalculated in Italy, e-mail systems shut down and ATM machines failed.

But the problems reported were far fewer than even the optimists anticipated. Energy, air-traffic control, water, heat, banking, medicine, transportation, government payment systems and a host of other areas have been finding and fixing glitches since the rollover. But to my knowledge, no one has died because of a Y2K problem, and global infrastructures are holding steady.

None of this is a total shock when we remember the original concerns that rallied the IT community around the year 2000 problem during the early 1990s. Before folks with little knowledge of computer systems began beating their chests about the end of civilization, Y2K was a systemic problem with the potential to ripple across systems and environments. Over the past few years, this original assessment of Y2K's impact was lost in people's concerns over our survival.

Y2K-related challenges to the human race quietly passed into the night during the rollover weekend. This leaves us with the mundane reality of applications, networks, non-IT systems and spreadsheets continuing to test year 2000 compliance for years to come. In the second book we co-authored, The Year 2000 Software Crisis: The Continuing Challenge (Prentice Hall, 1998), Ian Hayes and I compared Y2K to an old Chinese proverb called "death by a thousand tiny cuts."

These tiny cuts stem from miscalculations and the triggering of errant logic that contaminate data and force bad decisions. Post-rollover problems, driven by cycle dates or an odd set of conditions, may end up in related systems. Derivative errors can then result from bad data being used by internal and external systems that inherit that data. Some problems will be caught immediately, and others will be discovered down the road, or maybe never. All this can cause myriad problems, especially with inventory, distribution, tracking and financial systems.

With the threat of Armageddon stripped away, we're left with a relatively boring story. Don't get me wrong: Some embedded systems can loop for a while and fail later. Others may fail on leap day or at year's end. All this may provide some temporary media excitement, but it's unlikely to be any worse than the Jan. 1 rollover.

Remember that several hundred problems have been filtering into media reports since the rollover. Now consider that for every problem reported, there are likely hundreds that went unreported. That's still low, but consider that for every few problems we catch, a few more errors may go undetected. That's what we should worry about.

The reality of the Y2K bug sneaks up on companies and doesn't explode in the course of a single evening. It's complex, hard to identify and fairly run-of-the-mill. Time will tell if these problems get an honorable mention in the Y2K media frenzy or avoid the spotlight. In the meantime, let's keep our eyes and minds open as we move through the year

http://www.computerworld.com/home/print.nsf/all/000124E212

-- Martin Thompson (mthom1927@aol.com), January 31, 2000