The Y2K Bust

[article]
Summary:

Where were you on 31 December 1999? Celebrating on a beach in New Zealand, one of the first places in the world to experience the new millennium? Or in your office, hastily testing changes to old computer systems (with all vacation requests denied for a period of six weeks before and after New Year's Eve)? After all, the cover of BusinessWeek magazine had used the term "Global Financial Meltdown" to describe the concern. With hindsight, what have we learned about testing and quality assurance from the year 2000 problem (also called the Y2K or Millennium Bug)? For the last two years nobody has wanted to talk about it-but it should now be safe to bring up the topic.

As a consultant, I found the Y2K scare to be a profitable venture. Fear is a great motivator, and organizations that for years had under-invested in testing suddenly decided that money was no object. (Fortunately, I did not publicly say anything too stupid about the end of civilization and the cockroaches inheriting the earth, so I don't have any embarrassing statements to retract.)

In 1997, the University of California-Berkeley, asked me to make a series of television programs about Y2K for their executive education network. (This is a subscription-only network run by Berkeley.) The university had great expectations, but to their disappointment the series was a bust-very few CEOs, CFOs, or CIOs tuned in to watch.

At the time, I thought the problem was that we were too late with the message. Presumably, these forward-looking executives were already on top of the issue and did not need to know anything more. Over the next several months, the truth dawned that actually we were way too early. In 1997, Y2K was not yet on many radar screens.

The perspective of internal employees-who had to do all the work to repair, replace, and test systems, instead of merely talking about it-tended to be different from that of outsiders. Often these people were "volunteered" for projects that were not technically innovative, forcing them to miss new opportunities such as learning about the Web and to spruce up skills in old technologies that quickly became obsolete after Y2K; furthermore, they were subjected to intense deadline pressures and anxious managers looking over their shoulders. But they were promised the undying gratitude of their organizations for staving off potential disaster.

Background to the Problem
The year 2000 problem started many years ago when the data storage in computer systems was scarce and expensive. To conserve data storage, software engineers adopted the practice of representing dates with two digits for the year instead of four digits. For example, the year 1977 was represented by "77" in storage and in all date-based comparisons and computations.

The requirement to use only two digits for the year was even mandated by a U.S. government standard (FIPS), which was intended to be followed by all government agencies.

The unstated assumption was that all these systems would be obsolete and replaced well before the year 2000 arrived.

As a result of the two-digit years, on January 1, 2000, computer hardware, operating systems, databases, and application systems that had not been updated would effectively reset their internal clocks to January 1, 1900, or some other incorrect date, or refuse to operate.

In other words, without costly, risky, and time-consuming renovation or replacement, millions of existing computer systems were destined to fail at the end of the last millennium.

Imagine the following "day in the life" scenario. We had a lot of fun videotaping this scenario as the three-minute introduction to the Berkeley TV series, using one of the camera crew as the actor:

You are enjoying a quiet day at home, but feeling (and looking) mildly hung-over after indulging in a somewhat hectic holiday celebration the night before. (The actor looked appropriately disheveled.) The mail arrives. You toss out the junk mail and open your credit card bill. The restaurant meal of $38.92 you charged three weeks ago is on the bill, plus a late charge of approximately $1.8 billion (at 18% annual interest, compounded monthly for 99 years).

You pick up the telephone and cannot get a dial tone. Your telephone and  Internet accounts have been canceled. According to their records, the  communications utilities stopped trying to persuade you to pay

Pages

Tags: 

About the author

Ross Collard's picture Ross Collard

Ross Collard is a consultant who currently is working on software testing and quality assurance projects for AT&T, Cisco, GE, Lucent, and the State of California. He teaches software testing for UC Berkeley. Ross has an MS in computer science from the California Institute of Technology and an MBA from Stanford.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!