As the year 2000 rapidly approaches, an anxious clock is ticking for the world business community: When the twentieth century ends, many software applications will either stop working or produce erroneous results because their logic cannot accept the transition from 1999 to 2000. This problem is embedded in millions of aging software applications, and the costs of fixing the year 2000 software problem may constitute the single greatest expense in history.
In this new book, Capers Jones offers a framework for examining the effect that the year 2000 problem will have on your company, placing this timely issue into a practical business perspective. The Year 2000 Software Problem explains what it will cost to address this impending issue, quantifying the expenses by country, industry, programming language, and application. The book further examines the expected results of not achieving year 2000 compliance and estimates what the damages and recovery costs will be.
Highlights include:
An executive overview of the year 2000 problem and why it is significant
A discussion of the impact of repairing databases, repositories, and data warehouses
An explanation of the litigation risks and liability issues associated with this problem
A description of the important topic of year 2000 testing
The information contained in this book will allow you to fully understand what needs to be done to minimize the risks and problems that the year 2000 problem will inevitably bring. The author's pragmatic approach allows you to assess the scope of the problem, identify the appropriate solution strategy, and test and measure the effectiveness of your solution implementation.
From the Inside Flap
For more than 12 years my company and I have done research on a variety of software issues. Our consulting work includes performing qualitative assessments, and also the collection of quantitative data on software costs, productivity, schedules, quality, and a number of related subjects.
We collect this data in order to develop and tune the algorithms for our main commercial software tools, which are software cost and quality estimation tools: Checkpoint" and the more recent KnowledgePlan' which came out just as this book was being drafted.
Because we have a substantial volume of information on software maintenance and quality, both of which are relevant to the year 2000 issue, I decided to write a short technical report for our clients in 1996 on the probable costs of repairing the year 2000 problem.
We have been working for several years on cost estimating the software portions of the year 2000 problem, although neither our tools nor anyone else's can handle topics such as the litigation costs for year 2000 damages.
As I began to assemble the information and write the first draft, it quickly became obvious that the year 2000 problem was going to be a major issue for the world software community and also for the world business community. Once I realized the vast significance of the year 2000 problem, I continued to expand my initial report roughly every six weeks through eight additional versions.
By the time I reached version 5 early in 1997, other year 2000 authors had seen my data on our web site (spr) and requested permission to use some of it in their books. For example Dr. Leon Kappelman, Dr. Dick Lefkon, Dr. Howard Rubin, Dr. Keith Jones, and Bryce Ragland have all used some of my cost and economic findings in their own excellent books on the year 2000 problem.
By the time my report reached version 7 it had grown to more than 120 pages and I began to think in terms of a book of my own, since it was obvious that the year 2000 problem is almost unique in human history. There has never been a man-made technical problem which will impact so many businesses, so many government groups, and even cause so many problems at a personal level.
Since I've reviewed four books, six book drafts, and another dozen book proposals for the year 2000 problem, I know that there is a great deal of valuable information already in print on this subject, or about to be printed in 1997. It is a fair question to ask what my book might discuss that is not already available in the books of other authors.
The primary information contained here, but not really available from other books, is the quantification of two key topics: What will it cost to fix the year 2000 problem by country, by industry, by programming language, and by application. For the year 2000 problems that slip through and are not fixed, what will the costs be for immediate damages, and then for long-range recovery.
There are numerous excellent books on the technical 2000 problems, on how corporations might address and deal with those problems, and on some of the sociological and technical damages that might occur if the year 2000 problem is not fixed in time. However, there is no other readily available published source of information that addresses the full gamut of year 2000 costs, including: Portfolio analysis Software repairs Data base repairs Test library repairs Hardware upgrades Litigation expenses Potential damages from litigation Year 2000 failure costs Year 2000 recovery costs
My data for the entire spectrum of the year 2000 issue has a significant margin of error. However, by the time the errors could be eliminated and the data validated in order to achieve high accuracy, it would already be the year 2000 and hence far too late for the data to have any value.
There are other sources of quantitative data on the year 2000 problem, but they are not readily available to the general public. Several information service providers such as Gartner Group, Meta Group, and Giga Group provide quantitative data to their clients, but not very much of this data is available to non-clients.
The structure of this book is far from perfect, because the book grew organically and spontaneously rather than as a planned document.
Chapter 1 is a short executive overview of the year 2000 problem and why it is significant.
Chapter 2 discusses the origins of the year 2000 problem, and some related problems caused by attempts to conserve storage (a goal which is still causing problems even today).
Chapter 3 introduces the key terms and concepts that describe the nature of the organizations and applications which must deal with the year 2000 issue.
Chapter 4 deals with a very important but controversial point: the use of "lines of code" (LOC) metrics or "function point" metrics (or both) for quantifying the year 2000 problem. This chapter concludes that the very common LOC metric is actually hazardous, and some of the common ways of enumerating this metric can lead to severe over charges by contractors and outsource vendors.
Chapter 5 deals with the size of the year 2000 problem for the United States, including some special liability issues for U.S. corporations and U.S. executives.
Chapter 6 deals with the important topic of year 2000 testing, and the under-reported topic of errors in year 2000 test cases.
Chapter 7 deals with impact of repairing data bases, repositories, and data warehouses. The year 2000 problem is particularly severe and expensive in the data arena, and the costs cannot be measured using either lines of code (LOC) metrics or function point metrics.
Chapter 8 deals with the risks of litigation associated with the year 2000 problem. Unfortunately the risks of litigation are both plentiful and severe, and may include personal suits for violation of fiduciary duty against many senior executives.
Chapter 9 deals with risks of business failure associated with the year 2000 problem. Here too, the risk of bankruptcy or business failure due to the year 2000 problem is alarmingly high.
Chapter 10 discusses the emergence of the year 2000 repair industry, which has expanded faster than almost any industry in history. It has gone from non-existence to having a set of 18 companies summarized as a new stock-market indicator in less than 24 months.
Chapter 11 discusses "masking" or some of the evolving forms of concealing the year 2000 problem over and above simply expanding the date fields from two to four digits. Topics such as encapsulation, bridging, and compression are discussed.
Chapter 12 expands the year 2000 problem from the United States to the world, and summarizes the probable expenses individually for large countries, and then in aggregate for the entire world. This chapter also discusses the conflict for resources between the year 2000 problem and the European currency conversion problem, which are on a collision course in terms of both schedules and resource requirements.
Chapter 13 discusses some of the complex issues with the costs of the year 2000 problem, and explains why the costs will vary widely from company to company, country to country, industry to industry, and even from city to city.
Chapter 14 is based on the assumption that many organizations will not successfully achieve year 2000 compliance before the end of the century. This disturbing chapter is speculative since the end of the century is in the future. However, it attempts to quantify the damages and recovery costs for almost 1,700,000 software applications which will still have latent year 2000 errors as the dawn arrives on January 1, 2000.
Chapter 15 builds upon the gloomy scenario in chapter 14, and discusses the defenses which companies, government agencies, and private citizens might take to minimize the risks and problems which the year 2000 problem will bring to pass. All of us will have problems and will need to take some evasive and corrective actions, but hopefully by the end of the century we will fully understand what needs to be done.
Appendix A provides a short overview of the sources of data used to construct the book.
Appendix B is an annotated listing of other year 2000 sources of information.
Appendix C is an annotated bibliography of other year 2000 books.
0201309645P04062001
See all Editorial Reviews
