YEAR 2000 Vendors


by Peter de Jager
ComputerWorld, September 6, 1993

The date change in the year 2000 - an event that may trigger fatal errors in mission-critical systems - is only 2,308 days away. Many IS people are unprepared or unconcerned.

Have you ever been in a car accident? Time seems to slow down as you realize you're going to crash into the car ahead of you.

It's too late to avoid it - you're going to crash. All you can do now is watch it happen.

The information systems community is heading toward an event more devastating than a car crash. We are heading toward the year 2000. We are heading toward a failure of our standard date format: MM/DD/YY.

Unfortunately, unlike the car crash, time will not slow down for us. If anything, we're accelerating toward disaster.

This is a good news/bad news story. First the bad news: There is very little good news. There is no way to avoid the fact that our information systems are based on a faulty standard that will cost the worldwide computer community billions of dollars in programming effort.

Perhaps more importantly, we are going to suffer a credibility crisis. We and our computers were supposed to make life easier; this was our promise. What we have delivered is a catastrophe.

The problem is twofold: the date issue itself and, more importantly, our reluctance to address the problem.


What exactly is the "problem"? To save storage space - and perhaps reduce the amount of keystrokes necessary to enter a year - most IS groups have allocated two digits to the year. For example, "1993" is stored as "93" in our data files, and "2000" will be stored as "00". These two-digit dates exist on millions of data files used as input to millions of applications.

This two-digit date affects data manipulation, primarily subtractions and comparisons. For instance, I was born in 1955. If I ask the computer to calculate how old I am today, it subtracts 55 from 93 and announces that I'm 38.

So far so good. But what happens in the year 2000? The computer will subtract 55 from 00 and will state that I am -55 years old. This error will affect any calculation that produces or uses time spans, such as an interest calculation.

If you have some data records and want to sort them by date (e.g., 1965, 1905, 1966), the resulting sequence would be 1905, 1965, 1966. However, if you add in a date record such as 2015, the computer, which reads only the last two digits of the date, sees 05, 15, 65, 66, and sorts them incorrectly.

These are just two types of calculations that are going to produce garbage. There are others.

The task facing us is to identify and correct all the date data and check the integrity of all calculations involving the date information. We must correct the data residing in all data files or write code to handle the problem.

The starting point

How do we identify the problem data and the associated calculations? We have few, if any, standards for labeling data used in date calculations. The only choice we have is to examine each line of code and make the necessary changes.

One IS person I know of performed an internal survey and came up with the following results: of 104 systems, 18 would fail in the year 2000. These 18 mission-critical systems were made up of 8,174 programs and data-entry screens as well as some 3,313 databases. With less than seven years to go, someone is going to be working overtime.

By the way, this initial survey required 10 weeks of effort. Ten weeks just to identify the problem areas.

How many systems do you have? How many lines of code do you have in your organization? How many data files? How many maintenance programmers?

The problem extends beyond mere calculations and into the I/O processes of every application. Can you enter 2000 into your data screen, or can you enter only two digits, forcing the input of 00? Can your hard-copy reports print four digits?

The crisis is very real and potentially very costly. Ken Orr, principal at the Ken Orr Institute, and Larry Martin, president of Data Dimensions, Inc., estimate that Fortune 50 organizations will each have to spend about 35 to 40 cents per line of code to convert all their existing systems to accept the change from the year 1999 to 2000.

That translates into about $50 million to $100 million for each company. The mind boggles at a maintenance problem with that price tag.

And the costs could be even higher. "The truth is, until we work through a complete cycle with some large organization, we are not going to really know," Orr says.

I have spoken at association meetings and seminars, and when I ask for a show of hands of people addressing the problem, the response is underwhelming. If I get one in 10 respondents, I'm facing an enlightened group.

Typically, all I get are snickers and comments such as, "I won't be in this position or this company in the year 2000. It's not my problem."

This attitude in the computing community is the real problem. It is very difficult for us to acknowledge that we made a "little" error that will cost companies millions of dollars. It is also a "pay me now or pay me later" situation.

"We in the IS industry have not been paying our way," says Gerald Weinberg, author of Quality Software Management and winner of the 1991 J. D. Warnier Prize for Excellence in Information Science. "We have been building up a 'national debt' just as surely as the U.S. has been building up a money debt. It will be paid by our children - our successors - one way or another," Weinberg says.

We don't have a choice. We must start addressing the problem today or there won't be enough time to solve it. Status quo means applications that will produce meaningless results in the new millennium.

Weinberg says he believes this procrastination is an indication of deep management malaise. "If software engineering managers cannot manage a change that they've had 1,000 years to prepare for, how can we expect them to manage a change that happens without notice? In other words, if this change causes a crisis in your organization, everything will cause a crisis in your organization - and often nothing will cause a crisis."

The inability of the industry to even think about such a project is troublesome. "No one wants to step up to the issue - not [IS] management, not the vendors, not the industry gurus," Orr says. "As with all legacy systems, this problem is messy, expensive and unromantic. No one wants to go in and tell management they have a multimillion-dollar requirement just to keep the business running and that they really have no options."

The reason that nothing is being done, says Capers Jones, chairman at Software Productivity Research, Inc., is that the software industry isn't used to taking long-term preventative steps. "I expect that most companies will not start worrying about the problem until 1999," Jones says. "For some, this will be too late."

Now the good news

There is good news. Object-oriented systems may be able to help. Faced with the huge maintenance costs of fixing their systems, firms may opt to rewrite systems from scratch using object-oriented programming techniques. Tom Love, IBM vice president of the Object-Oriented Group, is a proponent of this theory.

Some companies are unveiling testing and inventory tools that may ease the identification of trouble spots.

Others are hoping that bombarding people with information is the best remedy. To that end, William Goodwin in Brooklyn, N.Y., publishes a newsletter entitled "Tick, Tick, Tick," which brings together people in the IS industry concerned about the impact of the year 2000.

But is the warning falling on deaf ears? "I feel like a lone voice crying in the wilderness," says Brian Pitts, one of Goodwin's subscribers and a project manager at Berry Co. in Dayton, Ohio. "Current economic conditions are making this problem more difficult to address. Management is focused on short-term results and is placing long-term negative consequences on the back burner."

The next seven years will be filled with dire predictions. "You are going to become very, very tired of millennium moaners telling you that your software will fail as it enters the new millennium," says Nicholas Zvegintzov, publisher of Software Maintenance News. "But be patient with them. There really is something to be said for them."

Peter de Jager is an industry speaker on the topics of change, creativity, and management technology.

A 50 minute Year 2000 video tape "Year 2000: Are You Ready?" and a 60 minute Year 2000 audio tape "Systems for the year 2000: The Upcoming Date Crisis" from de Jager are also available through this web site.

Vendors Archive Jobs 2000 Products Announce List Y2K Home
Search User Groups Links Y2K WIRE Press Services Conferences Stock Quotes