"The Year 2000 Software Problem", Capers Jones, 1998, 0-201-30964-5,
%A Capers Jones
%C P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario M3C 2T8
%I Addison-Wesley Publishing Co.
%O U$29.95/C$41.95 416-447-5101 fax: 416-443-0948 firstname.lastname@example.org
%P 335 p.
%T "The Year 2000 Software Problem: Quantifying the Costs and
Assessing the Consequences"
"When the twentieth century ends, many software applications
will either stop working or produce erroneous results since
their logic cannot accept the transition from 1999 to 2000,
when the dates change from 99 to 00 ... The costs of defending
against litigation and lawsuits can approximate half a year's
software budget, but damages and penalties from suits that are
lost can reach multiples of annual software budgets and lead
to bankruptcy ... Unfortunately, current data indicates that
at least 15% or software applications will not be repaired in
time." - from the Introduction
This book is a warning. By its own admission, however, it comes too
late. Is this book simply an insightful and focused locking of the
barn door after the horse has left the building?
Chapter one provides an executive overview of the situation. It shows
that year 2000 repairs should have started some time ago. However, it
does also demonstrate that it is barely possible to start such repairs
now, provided heroic measures are undertaken. It also proves that
such repairs then would have been much less costly than the same
repairs now, and furnishes rough, but well supported, estimates of
costs for the repair of applications, and for the failure to repair.
A historical review in chapter two also notes that there is a benefit
to the year 2000 problem: it will force companies to pay attention to
their software inventory. Chapter three is rather odd, defining a
handful of terms associated with applications development. The common
metric for year 2000 work is the number of lines of code to be
checked. Jones prefers the function point, and chapter four looks at
conversion factors plus a glance at the size of the problem as a
whole. However, it also starts to deal with direct and indirect
costs, particularly in regard to litigation, and loses some focus
thereby. Chapter five is a very thorough (perhaps at times overly
thorough) assessment of the total impact of the Y2K problem on the
United States, looking at the total cost, and cost by state, industry,
programming language, and so forth.
Advice on the actual fixing of the problem starts with program testing
in chapter six. Chapter seven looks very briefly at database repair.
Litigation and liability is reviewed in chapter eight. The analysis
of business failure risks, in chapter nine, seems to lean heavily on
litigation as well. Chapter ten discusses the rise of the year 2000
repair industry. Retrofitting applications by the use of masking or
windowing is mentioned in chapter eleven. The heavy United States
emphasis of the book is partially rectified in chapter twelve. The
analysis of the scope of the project by country is somewhat flawed by
assumptions that figures per line of code can be directly converted
from US surveys. However, the chapter also looks at the impact of
conversion to the Euro (the new European currency) and the diverse
impact this may have on the problem as a whole. Chapter thirteen
looks at factors that modify costs for various industries.
Chapter fourteen examines a number of problems that may arise in
various sectors if the problem is not fixed in time. A review of
general defensive tactics is contained in chapter fifteen. Appendices
B, C, and E contain additional sources of information.
In general terms, the book does not give much in the way of advice for
dealing with the crisis except for the suggestion to use masking in
preference to date field expansion. However, it does provide you with
some lovely frightening figures to use next time the CEO asks you if
this Y2K thing is really of any importance.
copyright Robert M. Slade, 1998 BKY2KSWP.RVW 980410