BKY2KSWP.RVW 980410 "The Year 2000 Software Problem", Capers Jones, 1998, 0-201-30964-5, U$29.95/C$41.95 %A Capers Jones %C P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario M3C 2T8 %D 1998 %G 0-201-30964-5 %I Addison-Wesley Publishing Co. %O U$29.95/C$41.95 416-447-5101 fax: 416-443-0948 bkexpress@aw.com %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