Table 3. Year 2000 Damage Probabilities Assuming Latent Date Problems

Year 2000 Problem Probability of Occurrence Bad credit reports due to year 2000 errors 70% Cancellation of year 2000 liability insurance 60% Loss of local electric power (> 1 day) 55% Litigation against corporate officers 55% Loss of regional electric power (> 1 day) 40% Loss of international telephone services 35% Errors in 2000 tax reporting (1099 forms) 35% Errors with social security payments 35% Errors in first January paycheck 30% Errors or delays in tax refunds 30% Delays or cancellations of airline flights 25% Loss of local telephone services 20% Errors with motor vehicle records 20% Medical or hospital billing errors 20% Manufacturing shut-downs (> 1 day) 20% Process control shut-downs (> 1day) 20% Reduction in stock values 20% Errors in 2000 tax reporting (W2 forms) 15% Errors in bank account balances 15% Disruption of stock market trading 15% Shut-down of pharmaceutical manufacturing 15% Errors in hotel/motel reservations 12% Delays or cancellations of shipping 10% Errors in prescription dates 10% Delays in UPS, FedEx deliveries 10% Delays or cancellations of rail shipments 10% Urban bankruptcy due to year 2000 7% Water shortages/rationing 7% Corporate bankruptcy due to year 2000 5% Food shortages/rationing 3% Escheatment of bank accounts 2% Death or injuries due to year 2000 1%

The highest probability is that we will have bad credit reports filed against us due to year 2000 problems which make us seem to be late in payments. This problem is almost certain to occur because there are just too many credit cards and billing systems in the United States for all of them to be fixed.

The major factor leading the credit situation is not the credit-reporting companies, but the fact that many paychecks and disbursements such as medicaid may be missing or incorrect. In addition, many invoices may be in error so the recipients may refuse to pay them. In addition, there is an assumption that many tax forms such as W2s and 1099s may be in error thus leading to audits for problems outside the control of tax payers. Indeed, there are also assumptions that neither federal nor state tax agencies will be year 2000 compliant themselves, so many of the problems will not be the cause of the taxpayers but rather of the tax agencies. However, errors on the part of tax agencies are usually passed on to the taxpayers who end up with the de facto burden of proof.

Another very high probability risk is that we will lose electric power for at least a day, and possibly for more than a week. Electric power plants in the United States are highly computerized and the year 2000 problem is endemic within this industry. Worse, experiments by electric companies to test out their year 2000 repairs have indicated worse problems and longer outages than anyone envisioned. These date problems are found in every form of electric generation: hydro electric, coal, and nuclear. They are often obscure and difficult to both find and fix.

Errors with government services are also in the high-risk category. The CIO of the U.S. Internal Revenue Services (IRS) has already stated that the IRS would not be ready, for the year 2000 and many other government agencies will not be ready either.

Payroll errors in January of 2000 accompanied by errors in the calculations of tax information for calendar year 1999 also have a high probability of occurring. There are too many local payroll and tax calculation software packages for all of them to be repaired.

Table 3 has a high margin of error, but several factors make at least some of the probabilities illustrated by the table distressingly likely to occur:

_ In 50 years of building and maintaining software, achieving 100% rates of defect removal efficiency has never happened for large systems development or large system enhancements.

_ It is highly unlikely that any company will achieve 100% efficiency in removing year 2000 problems, since many of the problems are resident in aging and poorly structured applications that are hard to test or inspect.

_ It is highly unlikely that indirect dates or complex date logic can be completely isolated or removed, or even fully tested.

_ The bad fix injection rates for year 2000 repairs are under-reported in the year 2000 literature, and are likely to be troublesome. Possibly as many as 10% of year 2000 repairs might create new defects. Although bad fixes are quite common, the topic of bad-fix injections is sparse in the normal quality and testing literature, and almost non-existent in the year 2000 literature.

_ Errors and defects in test cases and test libraries are under-reported in the quality and test literature, and almost non-existent in the year 2000 literature other than a section in the authors year 2000 book.

_ Many organizations with year 2000 software problems are not very sophisticated in software quality control and are not using state of the art defect removal methods.

_ Certification programs do not guarantee that 100% of year 2000 date problems will be found and removed. These certification programs merely testify that your year 2000 repair activities are prudent and energetic. There are software bugs in applications built by companies that are ISO 9001 certified and also at or above Level 3 on the Software Engineering Institute Capability Maturity Model (CMM). There will be year 2000 problems left over in companies certified by the ITAA and other year 2000 certification programs, and it would be naove to think otherwise.

In sum, there is no reason at all to assume that year 2000 defect removal efficiency levels will be any higher than the ranges for other kinds of software errors. Software quality has been a major embarrassment to the software industry for 50 years. It is naove to think that thousands of companies who were never very good in software quality control before the year 2000 problem will suddenly achieve higher than average defect removal rates for one of the toughest software problems in history.

Some of the major year 2000 service companies or major software producers equipped with capable year 2000 specialists, state of the art year 2000 search engines, and state of the art testing methods may be able top 99% for year 2000 defect removal efficiency levels or even hit the unlikely goal of 100% removal for well-structured applications which do not include complex or derived date logic.

However, ordinary companies attacking the year 2000 problems with untrained generalists, without year 2000 search engines, and using normal and informal testing stages are unlikely to go higher than 90% in year 2000 defect removal. If the software is particularly complex (modules > 20 in terms of cyclomatic and essential complexity) and uses indirect or derived date logic, then year 2000 repair efficiency levels can be lower than 80% and the bad-fix injection rate can top 15%.

Summary and Conclusions

The year 2000 software problem is a very difficult technical issue because software itself is a difficult topic. Since as this is written we still have almost two years to go before the year 2000 event, the exact nature of the damages are still uncertain.

If year 2000 repairs are active and energetic, then it may be possible to achieve or top 95% defect removal efficiency levels and hence face only minimal year 2000 damages.

If year 2000 repairs are sluggish and partial, which is the current situation for many organizations, then it is unlikely that more than 80% to 85% of year 2000 date problems will be found, thus leaving 15% to more than 20% of the date problems still latent at the end of the century. In this case, damages will be severe.

Readings and References

DeJager, Peter and Richard Bergeon; Managing 00 - Surviving the Year 2000 Computing Crisis; John Wiley & Sons, 1997.

Jones, Capers; Assessment and Control of Software Risks; Prentice Hall, 1994; ISBN 0-13-741406-4; 711 pages.

Jones, Capers; Patterns of Software System Failure and Success; International Thomson Computer Press, Boston, MA; December 1995; 250 pages; ISBN 1-850-32804-8; 292 pages.

Jones, Capers; Applied Software Measurement; McGraw Hill, 2nd edition 1996; ISBN 0-07-032826-9; 618 pages.

Jones, Capers; The Year 2000 Software Problem - Quantifying the Costs and Assessing the Consequences; Addison Wesley, Reading, MA; 1998; ISBN 0-201-30964-5; 303 pages.

Jones, Capers; Software Quality - Analysis and Guidelines for Success; International Thomson Computer Press, Boston, MA; ISBN 1-85032-876-6; 1997; 492 pages.

Jones, Capers; Becoming Best in Class; SPR Technical Report; Software Productivity Research, Burlington, MA; January 1998; 40 pages.

Jones, Capers; Estimating Rules of Thumb for the Year 2000 and Euro-Currency Projects; SPR Technical Report; Software Productivity Research, Inc.; Burlington, MA; January 1998.

Jones, Keith; Year 2000 Software Crisis Solutions; International Thomson Computer Press, 1997.

Kappelman, Leon (editor); Solving the Year 2000 Problem; International Thomson Computer Press, 1997.

Lefkon, Dr. Dick (editor); Year 2000 Best Practices for Y2K Millennium Computing: Panic in Year Zero; Mainframe Special Interest Group (SIG) of the Association of Information Technologies (AITP); New York, NY.

Ragland, Bryce; The Year 2000 Problem Solver; McGraw Hill, 1997.

Robbins, Brian and Rubin, Dr. Howard; The Year 2000 Planning Guide; Rubin Systems, Inc.; Pound Ridge, NY; 1997.

Rubin, Dr. Howard; Survey of Year 2000 Preparations in Fortune 500 Companies; Meta Group, Stamford, CT; January 1998.

Ulrich, William and Ian S. Hayes; The Year 2000 Software Crisis - Challenge of the Century; Prentice Hall, Yourdon Press; 1997.

Yourdon, Ed and Yourdon, Jennifer; Time Bomb 2000: What the Year 2000 Computer Crisis Means to You; Prentice Hall PTR, Upper Saddle River, New Jersey; 1998.

-- Susan Barrett (sue59@bellsouth.net), November 21, 1999

Answers

Source and date of this document?

-- we'd (like@to.know), November 21, 1999.

Neat. I'd sure like to know about the methodology for these percentages.

Seems like the oil situation isn't mentioned (nor ocean shipping).

In addition, how can a local (55%) and regional (40%) loss of electric power for >1 day result in a manufacturing and process control shutdown >1 day of only 20%?

-- Dean -- from (almost) Duh Moyn (dtmiller@midiowa.net), November 21, 1999.

My last sadistics class taught me that they don't just add.

Night train

-- jes an ol footballer (nighttr@in.lane), November 21, 1999.