From: "Vladimir Z. Nuri" <vznuri@netcom.com>
Date: Fri, 11 Sep 1998 03:35:49 +0800
To: cypherpunks@cyberpass.net
Subject: IP: Looming Y2k Crisis
Message-ID: <199809110836.BAA11030@netcom13.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain




From: "Douglas E. Renz" <dougr@zlink.net>
Subject: IP: Looming Y2k Crisis
Date: Thu, 10 Sep 1998 15:53:12 -0400
To: "'Chris Ball'" <1stlight@mail.tds.net>, "'En_Agape'" <en_agape@prodigy.net>, "'Kim/Jr'" <jrandkim@juno.com>, "'Kristen'" <kristen_renz@juno.com>, "'Steve Cortese'" <Sccortese@juno.com>, "'Tom Young'" <tayoung@cottagesoft.com>

   36 Seemingly Innocuous Questions That Pry the Truth
  Out of Managers and Programmers Regarding the Year 2000
   (Y2K) Problem and Their Organization's Looming Crisis

                   (c) Gary North, 1997
                 http://www.garynorth.com

The author hereby gives permission to any reporter,
columnist, or journalist to e-mail a copy of this report
to any colleague in the profession.


                       INTRODUCTION

     The Year 2000 (Y2K) Problem is real.  If it weren't,
Chase Manhattan Bank would not have budgeted between $200
million and $250 million to solve it.

     Nobody knows what the fallout will be.  My Web site
offers summaries and links to documents posted all over
the Web.  But there are so many potential falling dominoes
that nobody can predict most of what's going to happen.

     We will be hit from all sides without warning.
Things that nobody is thinking about today will be
disrupted.  For example, the water-control locks on the
Panama Canal are controlled by a mainframe computer
system.  Jimmy Carter and Congress signed away the Canal
back in 1977.  It goes to Panama on January 1, 2000.  Will
the U.S. government fund this Y2K repair?  (Ha!)  If not,
what happens to the canal in 2000?  What happens to
shipping?  The government is not discussing this.

     Dominoes.  Nothing but dominoes.  Maybe you can find
some interesting ones locally.

     I have set up a closed discussion forum on my Web
site for reporters who are working on Y2K assignments.
You can post messages to each other.  Maybe it will help.
If you find an interviewing strategy that works better
than what I suggest here, let me know.  Meanwhile. . . .


          I.  EXPECT TO BE STONEWALLED OR MISLED

     This reporting assignment is easier for women.  The
company's PR department will assume that a woman doesn't
know anything technical.  The manager or PR flak may be
less guarded.  If you're a woman who majored in English
lit, let the public relations people know this early.

     For general background, read the cover story of
NEWSWEEK (June 2).  This is an accurate account.  If
anything, it is overly subdued.  You need to know what is
at stake internationally before you begin research on how
the Millennium Bug will affect your community.

     My report is no cure-all.  A well-informed manager is
going to be paranoid about a story on Y2K and his
organization.  You have to hope you wind up interviewing a
manager or spokesman who really doesn't understand the
problem.  The closer you get to the truth, the more that a
careful manager will raise his "deflector shields."

     "We cannot divulge any proprietary information."
     "Our contractor is in charge of this project."
     "No, he cannot speak with you about this."
     "Our vendors are taking care of this."
     "No, we cannot supply their names."
     "We are on schedule: late 1998."

     When you hear any of these, be assured: you're onto
something important.  To get the full story, you must now
earn your paycheck.

     You can invoke the time-honored, "We want you to have
an opportunity to tell your side of the story."  You may
choose to hand him a photocopy of the NEWSWEEK article.
"This paints a pretty glum picture.  I had hoped to find
out if things really are as bad as this report indicates.
If your organization is on top of this problem, I would
like to be able to report this to our readers."  You can
gently make it clear that a refusal to answer questions
will make the company's situation look bad -- maybe worse
than it really is.  If you can't get access to a
programmer, keep asking the spokesman questions, even if
you get "no comment" to all of them.  Write each refusal
down in your notebook.  This will make him nervous.

     The most important Y2K-threatened organizations in
your community are the public utilities: water/sewers,
natural gas, and above all, electricity (the national
power grid is at risk).  You could do a powerful series of
articles on just these.  They can't stonewall you as
easily as a private firm can.  They are politically
controlled.  You can go to members of the public utilities
commission, tell them they you're being stonewalled, and
ask for help.  Ultimately, public utilities commission
members will become personally liable if the system goes
down and they knew about it in advance.  You can even
print out two or three of the documents I've posted on my
Web site under "Litigation."  Hand these print-outs to one
or more of the PUC's members.  My site's address is:

http://www.garynorth.com

     A member of a public utility commission is at great
personal risk if he lies or deliberately misleads the
public, and then a disaster takes place.  Call it
"Chernobyl syndrome."  Ask one or more of them to run
interference for you.  You want the interview.

     If you absolutely can't get access to a programmer at
a public utility, print out a copy of this report and hand
it to every member of the public utilities commission.
Tell them they had better get these questions answered for
themselves, and soon.

     I know of only one detailed local Y2K study that is
easily available: the report on North Platte, Nebraska,
written by three Creighton University economics
professors.  I have posted it on my site under
"Government."  A front-page story on Dick Brich, the
programmer in charge of the county's computer system,
appeared in the May 1, 1997 issue of USA TODAY.

     To understand the programming problem, you need a
standard for comparison.  Here is a good one.  Social
Security has had 400 programmers working since 1991 to fix
its system, which has 30 million lines of code.  The SSA
discovered the problem in 1989.  As of 1997, the system is
still noncompliant.  (See my Web site's category,
"Government.")  Use Social Security your benchmark.


                 II.  WHAT IS THE THREAT?

     You should assume that the spokesman or manager who
has consented to be interviewed has no idea of what is
involved technically in a Y2K repair.  He does not know
how long it will take.  Neither does anyone else.  Nothing
on this vast scale has ever been attempted in the
Information Technology world.

     The company probably has an official deadline:
December 31, 1998.  This has been forced on management by
the threat of post-1999 litigation: a due diligence date,
just in case the repair fails.  At least a year of testing
is necessary to verify that the repair is bug-free or at
least manageable.  The question is: Manageable by how many
people?  Kathy Adams of Social Security says that a 1%
error rate is too high.  With either 43 million or 50
million monthly checks -- she invoked both figures on
separate occasions -- either 430,000 or 500,000 phone
calls would hit the branch offices within days.  It would
overload the SSA's system, she says.  (Her estimate is
just for month one.  What if these complaints all not
taken care of, and another 1% error rate happens again
next month?  SSA will get a cascading effect -- noise,
confusion, and telephone busy signals.  Shutdown!)

     Medicare expects to pay a billion claims in 2000.
What percentage of errors would overwhelm the system,
assuming the system doesn't shut down on Jan. 1, 2000?

     But the manager who is speaking with you -- think of
him as Dilbert's boss's boss -- has not thought about any
of this.  So, he has no idea what constitutes a failed
repair, short of an absolute shutdown.  His job is to
paint a happy-face picture for you and all other
inquirers.  If the company is facing a disaster, he
doesn't want you to find out, assuming that anyone in the
company has warned him, which is doubtful.

     Everyone in the company has an incentive to lie.
Dilbert is paid to write code.  He does not make waves.
Meanwhile, his boss is threatened with getting fired if he
tells senior management, "I can't get this project
finished on schedule.  The system will crash."  The boss
says his team in on schedule.  Who can check up on him to
find out if he's behind schedule?  Nobody in management.
He collects his pay until December 31, 1999, at which time
he turns into Maxwell Smart: "Sorry about that."

     Senior managers desperately want to believe the IT
department, so they don't ask further questions.  They
hope that all their competitors are in the same condition,
which is surely the case.  This is why bond-rating
services have refused to downgrade any organization's
bonds because of Y2K risks.  They're all equally at risk.


     III.  ASSESSING THE ORGANIZATION'S VULNERABILITY

     Here are the Six Fundamental Questions:

     1.   "In what ways is your system is dependent on
          dates?"  (It's is a soft-core version of this:
          "If you fail to fix this, what happens?")
     2.   "When did the company find out about Y2K?"
     3.   "At what stage is the repair: inventory,
          assessment, code-fixing, testing [ha!]?"
     4.   "How many lines of code are in the system?"
     5.   "How many programmers are working on it?"
     6.   "What is your deadline to begin testing?"

     It is a standard estimate that a skilled programmer
with a date-search software tool ("silver bullet") can
correct about 100,000 lines of code a year.  This number
is crucial to your final story.  If you can find out how
many lines of code the organization must correct and the
number of programmers working full-time on the repair, you
can estimate whether there is any chance they will get the
problem fixed.  By this I mean the local computer.  This
does not solve the ultimate problem: integrating a
repaired computer with other computers, which, if not
repaired, or repaired with a different approach, will send
bad data into the first computer, ruining the repair.
(There is no agreed-upon standard for Y2K repairs; every
programming team is on its own, all over the world.)

     Be generous.  Let's say that the programmers are all
hot-shots.  Let's say they can fix on average 10,000 lines
a month.  Multiply this by the number of months left until
the universally agreed-upon date for the beginning of
testing: December 31, 1998.  Then multiply this number by
the number of programmers.  This will tell you if the
outfit has a chance of meeting the deadline for testing.
If the programmers miss the deadline -- and in 85% of all
large-scale code revision projects, they do -- then this
outfit the equivalent of the Titanic.  Do you think that a
program that's at least 500 times more complex than your
word processor can be re-coded by a committee and not
suffer a crash or a major glitch the first time it's run?
They had better test it.  What happens if they don't have
time?  Second, what happens if the test crashes the new
system?  The Jan. 1, 2000 deadline is a brick wall.

     Normally, 40% of a Y2K repair budget must be
allocated for testing.  This means 40% of the time budget
unless proven otherwise.  It may be higher in complex
systems -- above 100 million lines of code.  The spokesman
may tell you the truth about the Y2K discovery date if
he's proud of it: 1995 or early 1996.  Keep thinking
"Social Security."  They found out in 1989, got started on
the repair in 1991, and it's still not compliant.

     "Which stage?"  He may not know at which stage their
repair team is.  If he does know, he may not want to tell
you.  Maybe the programmer in charge will, if he doesn't
think it's privileged information.  So, your goal is to
get the spokesman to turn you over to the senior
programmer -- or, better yet for information purposes, a
subordinate programmer, who probably has no idea of the
sensitivity of the information he possesses.



         IV.  DETOUR: "PACKAGED SOFTWARE SOLUTION"

     I don't count these among the 36 questions.  The
spokesman may tell you that they will soon buy a packaged
system.  If you were conducting this interview in 1992,
this might make sense.  Today, it's too late.  Packaged
systems for highly complex, highly customized software are
very expensive to buy and very time-consuming to
implement.  A packaged system is no panacea today.

     The problem is this: How can they port their old data
and operations to the new, date-compliant software?  This
job takes years.  (Some consultants say that it's now too
late to repair code in the old systems.  I'm of this
opinion.  But is there enough time to design and implement
a replacement system?  Management hasn't a clue.)

     He may tell you that they are switching to a
client/server system.  Ask how much the old system cost.
Unfortunately, he may have no idea.  The new system had
better cost at least five times as much, given the
difference in prices (inflation).  If the new figure isn't
at least five times higher than the old one, the company
doesn't understand the magnitude of the complexity of the
old system and the difficulty of switching.  (On this
point, I was advised by Cory Hamasaki, a full-time Y2K
programmer.  For his voluminous Web postings, as well as
his humor, search "Hamasaki" on www.dejanews.com )

[Side Note: in a July 2, 1997, letter to me, Hamasaki
reported on the U.S. government's present Y2K status.  He
lives near Washington.  "Everywhere I checked last year,
they said that they were either working on it or had
solved the problem.  This year, the same places are saying
that it'll be tough, but they're having meetings and are
doing their planning.  What will they say next year?  I
expect that they will finally be past denial, and the
screaming and scape goating will begin."]

     If he says they plan to outsource the job to India or
Ireland, ask: "Do you have a contract with the software
repair company yet?"  These companies are now booked up or
are close to it.  The shortage of mainframe programmers is
real, though not yet an insurmountable problem.  It will
become insurmountable in 1999.  A WASHINGTON POST story
predicts a U.S. shortage of 500,000 to 700,000.  Another
estimate places England's at 300,000.  (I have posted this
information on my Web site under "Too Late?")

     If the company has "outsourced" the project, request
an interview with the contracting firm's project manager.
If he says no, then you're onto something.  But if you
can't get additional information, the interview will be
much harder.  You will have to interview the person inside
the local outfit who serves as the technical liaison.


           V.  HOW TO GET ACCESS TO A PROGRAMMER

     After you ask the spokesman about the date they
discovered the problem, ask him a technical question that
seems to be important to you, but which is actually
designed to get him to let you get your interview with a
programmer.  I suggest this question:

     7.   "Which method of dealing with the problem
          have you chosen: encapsulation, windowing,
          or expansion?"

     He won't know.  It's a purely technical question.
Nobody with decision-making capacity in management would
know the answer.  So, his ego isn't involved if he says he
doesn't know the answer.  You must now press politely but
firmly him allow you to interview a programmer.

     What if he asks why you want to know?  Answer: "So
that I can estimate how their repair will integrate with
the repairs made by other firms in your industry."

     You do, in fact, need to know this.  This, in fact,
is the crucial Y2K issue.  Any repair of one system that
fails to integrate with the industry's other newly
repaired systems will either: (1) kick the local computer
out of the system or (2) bring down the whole system.  If,
for example, the banks don't get together on their fixes,
you and I will not be getting paid for our brilliant
writing skills in 2000 and beyond.  (Sad, but true.)

     If the spokesman thinks you're interested mainly in
techie-type information, he may leave you alone with a
programmer.  That's your goal.  If he insists on being in
attendance, you must ask questions that seem to be merely
technical, but which will get the programmer to tell you
facts that will enable you to estimate whether the
organization is going to make it.


                VI.  YOU AND THE PROGRAMMER

     The lower on the hierarchy he is, the less he knows
about what constitutes sensitive information.  Even if the
PR flak knows, he may be hesitant to tell the guy to shut
up.  He may not want to appear to be stonewalling.

     The more information you can get early, the less
vulnerable you'll be to a "no further questions"
announcement.  That's why your early questions should be
more technical.  They will seem innocuous.

     Ask the programmer about windowing, expansion, and
encapsulation.  The guy will know.  Ask him why they
adopted their approach.  The answer may or may not be
comprehensible.  Let him talk.  It loosens his tongue.
(OK, OK: loosens HER tongue.  This is no time to worry
about political correctness.)  He's in his element.

     8.   Ask to see some of the code.  It will be
          gobbledegook to you.  But ask to see it.

     9.   Ask the guy to tell you what he has to do to
          change a date.  Sit next to him at his screen
          and watch how he does it.  This will give you an
          education.  Also, it puts him in his element.
          He's more relaxed.  He's in charge.  Meanwhile,
          the spokesman is as clueless as you are.

     If possible, conduct the rest of the interview while
the programmer is staring at his screen.  It will give him
confidence.  Look at his screen or your notebook as much
as you can.  A lot of eye contact may make him nervous.

     You're after information about the number of lines of
code in the system.  Ask him:

     10.  "Would you have adopted either of the other
          approaches if you had been facing a system
          with fewer lines of code?"

     Let him talk code.  He feels more secure.  Then ask:

     11.  "How many lines of code are in the system?"

     If the spokesman doesn't intervene here, you've got a
story.  If it's 5 million lines or more, the outfit is in
big trouble.  It's a huge, complex system.

     Now you want to find out how many programmers are
working on it full-time.  Ask (12).  He might even tell
you.  Next:

     13.  "When did you begin the actual code
          repair?"

     If he says that they're still in the assessment or
inventory stage, this outfit is dead.  Management just
doesn't know it yet.  Any programming team that is not
actively repairing code today will be incapable of
finishing the job by 2000.  You will want to visit my Web
site for confirmation.  Read the California White Paper.

     Once you have the Six Fundamental Questions answered,
you can begin to evaluate the company's actual condition.
The spokesman may not know how to put all this information
together.  In fact, he probably doesn't know.  He may not
even see what you're up to when you ask about which stage
the repair is in.  If he does, he may invoke "proprietary
information."  Keep going: you're now after "no comments."


           VII.  ASSESSING THE TASK'S COMPLEXITY

     14.  "I've heard that there are more languages
          embedded in a system than just COBOL.  How
          many have you come across?

     Some systems will have 20 other languages.  Assembler
is one of the monsters.  Find out if any of the system is
written in Assembler.  (Most of the IRS's system is in
Assembler.  The IRS told Congress in June of 1997 that it
needs $258 million in 1998 to repair its system.  The IRS
may not get this money, given its admission in January,
1997, of its 11-year, $4 billion failure to consolidate
its system into one.  Interesting?)  Then ask:

     15.  "How difficult will it be to keep all of
          the languages and programs in this system
          to remain integrated after you've made the
          necessary date changes in the code?

     One major problem is the compiler: a piece of
software that fits all parts of the system together.  The
compiler that the original programmer used to build the
system was not designed to handle 4-digit dates.  It may
not have been updated -- in fact, probably has not been
updated.  The company that made it may be out of business.
So, if he mentions "compiler," pursue the matter, but
don't mention it first.  Remember, you're ignorant.

     Now go for the jugular.  You must play the "please
help me to understand all this" role.  You just don't
understand.  You had better hope that the flak doesn't
either, if he's still sitting in the room.

     What you're after here is information regarding the
vulnerability of this organization.  Which kind of dates
can blow up the system and why?  He won't tell you if he
thinks you're looking for bombs, but he'll tell a whole
lot if he thinks he's your new-found mentor.

     If you're looking at the screen or a print-out of
indecipherable code, look helpless.  Always look helpless.
You may even ask the spokesman to sit closer.  Let this
become a joint-learning experience.

     16.  "You use dates in your computer software
          and in old data records.  How do you or
          your software tools find them?"

     He probably won't volunteer that there are hidden
dates in the system's programs.  Dates are hidden in
subroutines that his "silver bullet" can't find.  Finding
these is a very difficult, time-consuming task.  Ask:

     17.  "Can the tool you use automatically find
          every date in the code?"

     It can't.  There is no such thing as a true silver
bullet.  This is why the task is so painstaking.

     18.  "How do you spot dates if they're not visible?"

     Find out.  He may tell you about the screwball names,
such as some old girlfriend's first name, that the
original programmer used to identify his clever,
undocumented code.  I emphasize "undocumented."  Ask:

     19.  "Do you have the original documentation in
          front of you when you do the search?"

     If he says the company doesn't have it (which is
probably the case), you've hit pay dirt.  Don't let your
face show it.  Say, "Boy, that must make your work hard."
It does.  Let him whine about it a bit.  Next:

     20.  "I'm having trouble understanding all this.
          Am I interpreting this correctly?  Is the
          problem that all of these dates are stored
          as mm/dd/yy or in any other combination
          that has yy instead of yyyy?"

     This is indeed the problem.  The fate of the world's
economy hinges on the solution to it.  Then ask:

     21.  "If your dates are not already in the yyyy
          format, do you have to go in and add the
          extra 2 digits, line by line, through the
          entire system, including all of the old
          data files?"

     Let him explain this to you.  Then. . . .

     22.  "Is it true that when you rewrite a single
          line of code, this can have unpredictable
          repercussions in other parts of the
          system?"

     Here is the terrifying truth -- a truth that
literally threatens the survival of our economy.  If a
programmer makes a date change in one line of code, this
can have unforeseen repercussions -- always bad --
anywhere else in the system.  This is why final testing is
crucial.  It is also why final testing will crash many
systems.  Then the team will have to start over: search
all of the lines of code for non-date anomalies (no date-
locating silver bullet tool can help here), rewrite the
affected code, and test again.  The system may crash
again.  It probably will crash again.  Time will be
running out.  All this testing, fixing, and re-testing
must be done in 1999.  This assumes that firms actually
meet the formal deadline for testing: December 31, 1998.

     This is why Chase Manhattan Bank (200m lines of
code), Citicorp (400m lines) and AT&T (500m lines) have
problems.  So do you and I if we expect the economy to
stay afloat after Dec. 31, 1999.

     23.  "If one change can crash the system, do you
          have to check every line of code in every
          program to insure that if a date is being
          used, it can accept the new date format?"

     He had better say yes.  If he says his "silver
bullet" tool can help him do this, fine, but he is still
limited to about 100,000 lines of code a year.  Ask him
how many lines of code he can fix in a year (24).

     Now, you must take him into new worlds where no man
has gone before.

     25.  "How will you test the system after all of
          the dates have been changed?

     He had better tell you by parallel testing: running
data into the original program and the revised one
simultaneously, to see if the revised system crashes.

     26.  "How long will it take to test all this?"

     If he estimates anything under six months, use this
for comparison purposes with other local systems.  The
larger the program, the longer the testing period should
be.  Now, for the killer, the one that is unanswerable:

     27.  "Won't parallel [mirror] testing require
          two times your computer capacity and
          staff?"

     If the spokesman lets him answer this, he has made a
big mistake.  The rule for mainframes is "24 x 7 x 365":
all year long.  These expensive machines are run all day
at 90% capacity except for routine maintenance in non-
prime time.  Here is the Achilles Heel for all of the Y2K
repair hopes: there will not be enough excess computer
capacity -- memory, data tapes, and staff -- to run full
parallel testing if every system that must be fixed is
brought to the testing phase.  On the other hand, if there
is no shortage in capacity, then it's because very few
firms have reached the testing phase.  (This is my bet.)
Finally, if systems aren't tested in 1999, most of them
will crash or act up to the point of uselessness in 2000.

     28.  "Does your firm plan to rent computer time
          in order to run the tests?"

     If he says no, ask how they can do in-house.  If he
says yes, ask this question:

     29.  "Where will you rent the excess capacity in
          1999 if other organizations are also
          looking to rent time on mainframes?"

     By now, the guy knows that you know they can't fix
it, test it, and implement it by 2000.  You've got your
story.  Nevertheless, keep on going if you're allowed to.

     30.  "Companies rely on outside vendors for some
          of their programs.  Have your vendors
          supplied you with Y2K-compliant updates?

     31.  "Most mainframes are not Y2K compliant, and
          currently no PC is.  Will you be replacing
          all of your computer hardware as well as
          your computer software?"

     32.  "Some of the firms that you interact may
          not make the deadline.  What steps will you
          have to take to insure data you get from
          other computers is also Y2K compliant?"


                 VIII.  BACK TO MANAGEMENT

     Now you can go talk to the spokesman back in his
office.  If he let you get this far, he doesn't understand
what you've got.  Move away from discussing his firm.
Discuss the industry.  This lets him relax.

     33.  "About how many suppliers does the typical
          organization in this industry rely on?"

     34.  "Is your firm typical, approximately?"

     35.  "Has the industry discussed contingency
          plans if some of its major suppliers should
          fail to meet the Year 2000 deadline?"

     Last question (36): "Where can I get copies of
anything that the industry has released on Y2K?"  If there
isn't anything, this industry is headed for a disaster.


                        CONCLUSION

     As the year 2000 approaches, this story is going to
move toward the front page of every newspaper.  As yet,
stories on local companies have been mostly tapioca
pudding.  Reporters are accepting at face value the happy-
face, "we're on top of this" PR interviews offered by
local managers.  The articles dutifully report the story:
"Yes, there's a problem, but it's being dealt with by the
[  ] company."  Fact: the only problem being dealt with
successfully the company is the reporter problem.

     If a local public utility goes down and stays down on
January 1, 2000, the days of wine and roses will end in
your community.  The larger your community, the greater
the problem.  It is fair to give people a warning if they
are really at risk.  But if they are at risk, nobody in
authority at the local public utility will want to admit
this.  Deferral has become management's job number-one.
This strategy works because nobody in the media blows the
whistle.  Reporters (as with almost everyone else) are in
denial about Y2K.  Deferral and denial are the Tweedledum
and Tweddledee of the Year 2000 story.

* * * * * * * * * * * *

                     ABOUT THE AUTHOR

     Ph.D., history, U. of California, Riverside.
Contributor, <The Year 2000 Problem: Strategies and
Solutions from the Fortune 100> (1997), edited by Leon
Kappelman.  





**********************************************
To subscribe or unsubscribe, email:
     majordomo@majordomo.pobox.com
with the message:
     (un)subscribe ignition-point email@address
**********************************************
www.telepath.com/believer
**********************************************