NODE 77b7bc4ey2k problem *serious*
"Vladimir Z. Nuri" <vznuri@netcom.com>Tue, 29 Jul 1997 09:07:33 +0800
some people have talked about the y2k problem here, the
"year 2000 problem". as programmers know, is the
name given to the glitches that are caused by software
malfunctioning because it only used 2 characters for the
date field. I have mentioned that I think government
agencies are going to be particularly hard-hit by this
situation. I envisioned delays in payments etc. of something like
a few weeks or so.
however some recent new data and analysis by someone
named Gary North causes me to rethink my position.
it's somewhat alarmist, but he's got some excellent evidence.
he believes the year 2000 problem is vastly more serious
than anyone has realized. he thinks it may even lead to
bank panics and instabilities in the entire worldwide
economic system.
he quotes Yourdon, a very respectable software professional, who
talks about the domino effect in software such that even
if parts of it are fixed, the erroneous sections can cause
the system as a whole to fail.
I suspect that we will be seeing some major, major news
events related to y2k over the next year, all the way up
to 2000.
more info on this perspective can be found at
www.garynorth.com
this will be an incredibly important issue for virtually all
programmers in the information field. (some cryptoanarchists
here might rejoice at the potential here for mass social
disruptions. may you live in interesting times.)
The Yourdon Report
Vol. 1, No. 4, June 1997. © Copyright 1997 by Cutter Information
Corp.
The Personal Consequences of Year 2000
Dear Colleague,
Where will you be on New Year's Eve, 1999? If you're involved in the
computer field in any way, there's a high likelihood that you'll be
frantically working on the last-minute details of a year-2000 project.
Yes, I know, not everything is written in COBOL and not every hotshot
Java programmer is interested in the problem. But if you're an
application programmer who normally develops business applications in
Visual Basic, PowerBuilder, Smalltalk, or COBOL, there's a good chance
that your organization will give you a temporary assignment to help
out with converting mission-critical systems that are too important to
fail. If you're a new-age Java programmer in a Silicon Valley startup
company, maybe you'll be able to ignore the whole thing; but for many
of the people who write software, 1998 and 1999 will be the years of
year-2000 death march projects.
I assume that anyone who reads this newsletter is familiar with the
basics of the year-2000 problem; I won't bore you with a repetition of
the details, or how we managed to get ourselves into this state. What
I do want to talk about is the notion that it's our organizations that
got themselves into this state, and that we have to make sure we
distinguish between the problems and demands of our organizations,
versus the problems and demands of our own lives and the lives of our
families and friends.
First, let's deal with the basic moral issue of culpability and
responsibility. As you well know, there are some enormous legacy
mainframe systems that will fall over and collapse on January 1, 2000,
unless a thorough, expensive, and time-consuming effort is made to
make them year-2000 compliant. But it's highly unlikely that you wrote
the original code for those systems; indeed, the original programmers
are probably long gone, maybe even dead. Or, ironically, those
programmers may have been promoted: They may be your boss, or your
boss's boss, or the CIO of the whole shop.
In the rare case where you actually worked on the applications that
now require year-2000 maintenance, chances are that nobody paid
attention 15-20 years ago if you recommended that the date be coded
with a four-digit year field. You were told how expensive memory was,
and that none of these systems would last through the 1970s, or the
1980s, or the 1990s.
In other words, with very, very few exceptions, the year-2000 problem
is not your fault. Maybe we should have been smarter 20 years ago, and
maybe we should have staged a mass revolt when our business users told
us that they didn't want to spend the money for an extra two bytes of
storage every time a date field was required within an application.
Maybe they didn't really understand the significance of the short-term
tradeoff that we made on their behalf. But after all, it was their
money and their systems. In any case, there's a good chance that you
can look at yourself in the mirror and honestly say: It's not my
fault.
Perhaps you feel that, as a member of a more-or-less professional
category of "knowledge" workers, we all share collective
responsibility for letting society get itself into the year-2000
dilemma. After all, what if mechanical engineers told us that a flaw
in their calculations would lead to bridges and buildings falling over
and crashing on January 1, 2000? What if they collectively shrugged
their shoulders and said, "Well, it's not our fault. Newton, Galileo,
and Einstein made a few miscalculations in their basic laws, and we
just realized the problem."
From that perspective, none of us really wants the IT community to end
up with a huge black eye, or with the blame for having caused a
massive economic and social disruption associated with year-2000
software problems. I'm willing to contribute some time and energy to
help solve the problem. I'm willing to say, "Well, it doesn t really
matter whose fault it is at this point. The most important thing is to
fix the problem, and then move on."
But what if the problem cannot be fixed? What if January 1, 2000,
arrives and half of your company's software has not been converted?
What if your organization collapses as a result? At that point, where
does your responsibility lie? The interesting thing about this is that
almost every organization could have fixed its year-2000 problem if it
had begun addressing the problem in 1995 or before. But if the
year-2000 conversion team is just forming now, in mid-1997, then the
conversion almost certainly won't be finished when New Year's Eve
rolls around two years from now. And that part of the problem is the
fault of senior management, which was too busy worrying about other
issues to focus on the biggest software project of all time.
Let me stop for a moment and address a basic point: Many software
professionals believe that the year-2000 problem will be somewhat
annoying, and somewhat expensive to fix, but they can't bring
themselves to believe that it could be a major, fundamental problem.
It's like asking the residents of Southern California if they really
believe that they're going to wake up one day and find that the San
Andreas Fault has finally ruptured, and that California is now an
island floating in the general direction of Hawaii. "We've lived with
plenty of earthquakes, and some of them have been pretty serious,"
these folks will tell you. "Someday, the Big One will hit, but I
really can't believe it's going to happen this year, or next year, or
the year after."
So here's the question: Do you believe the year-2000 problem is going
to be really serious? Do you think it could shut down telephone
service, banking systems, and airline systems for a few days, or a few
weeks, or even a few months? I've been thinking about all of this
during the last several months, and I'm becoming increasingly worried
about the "ripple effect" problems that will be difficult to
anticipate, and almost impossible to avoid. It won't be the end of
civilization, but the year-2000 problem could indeed trigger a
depression on the scale of the Great Depression in the U.S. during the
1930s. For example, consider XYZBank, which has 300 million lines of
legacy code. Assume that XYZ has the time and resources to convert 200
million lines, and it has done a triage to ensure that the
mission-critical systems are converted. That leaves 100 million lines
of unconverted code that won't run at all, or will spew out gibberish.
Since this unconverted code is associated with noncritical systems, it
won't have a fatal impact on XYZ though it could incur a nontrivial
cost. My real concern is that the applications XYZ considers
noncritical might be very critical to some of XYZ's customers,
partners, suppliers, etc. So it's quite possible that XYZ's failure to
convert some of its software will cause little, tiny ABCWidget Company
to go bankrupt, which causes slightly larger DEF Corp. to fold, and so
on.
Meanwhile, XYZ can't operate entirely alone; without electricity,
phone service, and water, the offices can't function; without
transportation services, none of its employees can come into work, and
none of its customers can visit the bank to transact business. Let's
assume for a moment that these basic utilities do continue operating
properly after January 1. But what if the Federal Reserve Bank,
S.W.I.F.T., and all the other banks that XYZ interacts with are having
problems? What if XYZ's ability to print monthly bank statements
depends on PQRPaper Corp. supplying laser-printing paper on a "just in
time" basis? And what if PQR has a staff of three overworked
programmers who maintain an ancient legacy system written in assembly
language? If PQR stops shipping paper, then XYZ stops sending bank
statements. Not forever, perhaps just for a month or two, but that's
enough to cause a lot of confusion.
There's also going to be a lot of confusion resulting from bugs
injected into the converted programs. If XYZBank converts 200 million
lines of code between now and December 31, 1999, then there will be an
enormous amount of testing, and with that much code it's inevitable
that some bugs will slip through. Maybe not fatal bugs that delete the
database or shut down the bank's systems, but perhaps the kind of bug
that will send incorrect monthly statements to 100,000 of the bank's 3
million customers. A problem like this might not be noticed until
January 31, or when the year-end statements are produced on December
31, 2000.
The problem with 100,000 incorrect statements is that it will generate
100,000 angry phone calls. Indeed, officials at the Social Security
Administration (SSA) are quoted as saying that if the SSA has a 1%
error rate in its retirement checks and other benefits, it will lead
to somewhere between 43 and 50 million phone calls, starting the day
after the checks are mailed. If the problem isn't resolved right away,
then those people are likely to call back the next day, and the day
after that, and the organization is likely to be in a state of
paralysis.
Back to the banks again: Do I really think that Citibank, Chase,
Chemical, and BankAmerica (along with all the huge Japanese and
European banks) are going to shut down on January 1, 2000? No, of
course not. But I won't be surprised if the XYZSavings and Loan in
South Poobah discovers that it can't process deposits and withdrawals
for a week or two. That problem might cause a run on the bank, or an
outright bank failure, and similar problems are likely to occur for a
number of other small organizations as well. General Motors (GM) won't
go bankrupt, but ABCWidget and PQR Paper could.
Indeed, if ABCWidget goes bankrupt, it could cause serious problems
for large companies like GM. Suppose ABC is one of the 100-odd
companies that supply parts for GM cars and the widgets manufactured
by ABC are an essential element of the transmission system. Because of
the lean manufacturing system used throughout U.S. industry today,
there's a good chance that GM doesn't have an inventory of widgets;
ABC is supposed to deliver the appropriate number of new widgets to
the GM plant every day. To ABC's surprise, its computers fail on
January 1, 2000, and its widget production line shuts down. A week
later, GM's production line grinds to a halt until it can find a
replacement widget manufacturer. Meanwhile, GM's factory workers are
furloughed without pay.
By now, I'm sure you get the drift of my concerns. The interesting
thing is that while software professionals and systems analysts are
well-equipped to understand the reasons why the software could fail,
and the possible consequences of those failures, they prefer to deny
it. I wasn't aware of this until I watched Peter de Jager's year-2000
presentation at our recent Summit 97 conference, which ended with a
question to the audience: "How many of you really believe these
problems will occur?" To my surprise, a significant number of people
raised their hands to indicate they did NOT believe that serious
year-2000-related failures would occur. They couldn't disagree with
any of the technical points that de Jager raised, just as you probably
won't find anything fundamentally wrong with my arguments here. But de
Jager's audience, and many of the people reading this newsletter,
don't want to believe things could be this bad. "Surely," people will
argue, "companies will find a way to solve this problem." Given our
track record for normal software projects over the past 30 years, this
argument borders on hysterical optimism. More likely, it's cognitive
dissonance: If the facts disagree with the conclusions you were hoping
for, then ignore the facts.
What does all of this have to do with your job? Well, first you need
to realize that a "denial of reality" may be taking place within your
own organization today. Has your CEO or board of directors made a
public commitment that all of the organization's systems will be
year-2000 compliant, and that there is a detailed plan for coping with
the organization's non-year-2000-compliant vendors, suppliers,
customers, etc.? Do some arithmetic: If your company has 100 million
lines of code in its application portfolio, then as of June 1, it
would need to convert more than 100,000 lines of code per day, every
day, in order to finish the job on time. Do you see the plans, the
people, the tools, and the management commitment to make that happen?
If not, what will be the impact on your job? Chances are that your
company will go into panic mode sometime in 1998, halt all of its
development work, and assign everyone in the IT department to work on
year-2000 conversions. When I say everyone, I mean everyone.
Secretaries will be drafted into the testing effort, and the managers
will be expected to begin writing COBOL code. Is that the kind of
environment, with everyone putting in double overtime, that you want
to work in? And if the year-2000 conversion isn't finished on time,
who will be blamed? You can be sure there will be lawsuits; are you
sure you'll escape the wrath of the lawyers?
If your company's year-2000 problems are very severe, what happens if
it goes bankrupt? Will you be able to get another job? (An even more
interesting question: At that point, will anyone want to admit that he
or she is a programmer, or will it be a social stigma after January 1,
2000?) If you're out of work for six months, do you have enough money
in the bank to support your family?
Speaking of banks, what if your savings account is in XYZSavings and
Loan of South Poobah? If depositors begin to worry about XYZ's
year-2000 compliance in late 1999, will they begin withdrawing all of
their money? If they do, will you be able to withdraw your money on
January 3, 2000? Indeed, given the delicate balance of the fractional
reserve system used by banks, it doesn't take a very large percentage
of panicky customers to cause a bank run. The worst-case scenario in
this area is pretty scary -- it might not be just the XYZSavings and
Loan that suffers a bank run, but the big banks too. If the banks
close for more than a couple of days, then how does the government
collect taxes? If the government can't collect taxes, what happens to
the value of its bonds, T-bills, and other financial instruments?
Meanwhile, how many non-year-2000-compliant railroad and trucking
companies will it take to disrupt the transportation infrastructure?
While you're thinking about this, keep in mind another aspect of the
lean manufacturing system -- the average grocery market, especially in
urban areas, has to be restocked every 72 hours.
I don't have answers for all of these questions, and I spend a portion
of each day wanting to believe that none of these crises will occur.
But I can't find a way to deny the possibility that they could occur,
not exactly in the way I've described, but as a series of
domino-effect problems that ripple through society. And if my software
experience allows me to anticipate some of this, then your experience
should provide similar insights. Think about this, and try very hard
to avoid the cognitive dissonance problem.
If the problem is anywhere near as bad as I think it could be, then
you have to think very carefully about your loyalties and priorities.
Will your employer get first call on your loyalty, or will it be your
family and loved ones? On January 1, 2000, will you be at your
keyboard, still converting two-digit year fields? Think about this
now, while things are still calm. It won't be so easy two years from
now. Ciao!
Ed
Internet: ed@yourdon.com
Web site: http://www.yourdon.com
NODE efc5675bRe: y2k problem *serious*
iang@cs.berkeley.edu (Ian Goldberg)Wed, 30 Jul 1997 00:56:06 +0800
In article <Pine.SUN.3.96.970729103454.11487B-100000@beast.brainlink.com>,
Ray Arachelian <sunder@brainlink.com> wrote:
>Also, the year 2000 isn't a leap year, but most PC's will think it is.
Sigh. It boggles the mind how many people know the 100-year exception to the
"divisible by 4" rule, but don't know the 400-year exception to the exception.
>From http://www.boulder.nist.gov/timefreq/faq/q28.htm :
Is the year 2000 a leap year?
The year 2000 will be a leap year. Century years (like 1900 and 2000)
are leap years only if they are evenly divisible by 400. Therefore, 1700,
1800, and 1900 were not leap years, but the year 2000 will be a leap year.
To understand this, you need to know why leap years are necessary in
the first place. Leap years are necessary because the actual length of
a year is 365.242 days, not 365 days, as commonly stated. Therefore,
on years that are evenly divisible by 4 (like 1992, for example) an
extra day is added to the calendar on February 29th. However, since the
year is slightly less than 365.25 days long, adding an extra day every
4 years results in about 3 extra days being added over a period of 400
years. For this reason, only 1 out of every 4 century years is considered
as a leap year.
Note that (from http://www.boulder.nist.gov/timefreq/ :)
The Time and Frequency Division is an operating unit of the Physics
Laboratory of the National Institute of Standards and Technology
(NIST). Located in Boulder,Colorado at the NIST Boulder Laboratories,
the Time and Frequency Division:
o Maintains the primary frequency standard for the United States.
o Develops and operates standards of time and frequency.
o Coordinates U. S. T&F standards with other world standards.
o Provides time and frequency services for United States clientele.
o Performs research in support of improved standards and services.
So if NIST says 2000 will be a leap year, that would seem to be "official"
(at least for the US).
- Ian "who's going to be sorry he bothered responding"