----------------------------Original message----------------------------
This article contains a warning about which we all need to be concerned.
Responsibility to address the things discussed are currently being relegated
to "they" (whomever "they" comprises), by the statement "They will be sure it
won't affect us." But if we little people don't start making noises, "they"
will ignore it for as long as possible.
Debbie Lords
[log in to unmask]
****** START OF FORWARDED MESSAGE ******
Originally-From: "Peter de Jager" <[log in to unmask]>
Greetings,
I've gotten permission from ComputerWorld to post the attached
article on the Internet. If you feel your maillist would be interested in
reading it then please post accordingly. The only condition is that
everything between the lines of =========== must be included in the
posting.
Yours truly
Peter de Jager
============================================================================
ComputerWorld
Sept 6th 1993 - In Depth article
Doomsday 2000
-------------
by Peter de Jager
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
Problem ID:
-----------
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 milions of applications.
This two-digit date affects data manipulation, primarily
substractions and comparisons. For instance, I was born in 1955.
If I ask the computer to calculate how old I am today, it
substracts 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 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 Institutes, 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 nothing is being done, says Caper Jones, chairman at
Software Productivity Research, Inc., is that the software
industry isnt'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 no 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 bings
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 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."
"Copyright 1994 by CW Publishing, Inc. , 375 Cochituate Road, Framingham,
Mass. 01701. Reprinted by permission of Computerworld."
Sept 6th 1993 - In Depth article
Author:
Peter de Jager
Speaker on Change & Creativity & Issues relating to Computers
Brampton, Ont, Canada
Tel: (905) 792-8706 Fax: (905) 792-9818
Internet: [log in to unmask]
This article may be reposted on two conditions.
1) The author is notified of the reposting
2) The complete copyright notice is included in the reposting
|
