The Year 2000 problem is emerging as one of the most expensive accidents in history. Its costs will certainly exceed that of the Kobe as well as the Los Angeles earthquakes plus hurricane Andrew (only $170 billion). In consequential damages it is likely to get more public attention than the tobacco, asbestos, exploding gas tanks and breast implant incidents all put together.

It is mandatory to become realistic now not only about the costs but also about the "collateral damages" - to use a government euphemism - of this most costly technology-induced case of managerial negligence.

Mis-estimates

• Concentration on Limited Scope: The Year 2000 preparedness exercises concentrate primarily on what is under the direct control of the CIOs, such as financial, accounting, billing and customer-related systems. Yet, the most public mischief will be caused by the failure of embedded systems that are rarely under any coordinated control, such as building security systems, time locks in bank vaults, aircraft maintenance monitors, railroad safety devices, global positioning satellites, logistics tracking, manufacturing and process computers, and so forth.

• Neglect of Testing Programs: There is no point in fixing an application if it cannot be independently tested and verified. In well managed organizations the testing programs can account for as much as 30% of the code inventory. The upgrading, verification and validation of this code is materially more expensive than for general applications. Even more serious is the total absence of any testing programs for most legacy systems. In the case of embedded applications, the testing routines may be available only from the original suppliers. Even then, this software would work only if someone maintained configuration control all along, which is extremely rare.

• Inapplicability of "Lines of Code" Estimates: It is demonstrable that the count of the lines of code bears no relationship to the complexity of an application as measured by "Function Points." For instance, it make take anywhere from 200 to 450 lines of assembly code to define a single "Function Point" whereas SmallTalk may take only 15 to 40 lines to perform the identical task.

• Depending on Cost/Per Line Estimates: Perhaps the greatest persistent mistake is to rely on often quoted costs of remedying applications, such as the steadily upward drifting Gartner numbers of cost per line of code. These estimates assume the availability of diagnostic, remedial and testing tools for the most popular languages such as COBOL and C. However, these popular compilers account perhaps for as little as 45% of the inventory. The balance is made up of more than sixty languages such as Pascal, PL/1, Ada, Jovial plus supplier-specific assembly languages. The costs of making the necessary Year 2000 fixes will therefore vary greatly depending on the availability of tools and expertise.

• Omitting of Data Base Rectification Tasks: Everyone is concentrating on fixing code logic. Making sure that database records remain usable may take at least as much effort as the initial software repairs.

• Overlooking Litigation Expenses: After examining all of the evidence as to the difficulty of the Year 2000 tasks and after considering the available resources as well as timing I concluded that a widespread epidemic of systems failures will surely take place.

  Lawyers know that willful disregard of a known danger can be construed as an act of negligence. Litigants appreciate that such cases offer enormous opportunities for collecting big damages and exorbitant legal fees. There will be sufficient plaintiffs to make sure that the year 2000 problem will be tried as a managerial liability before local juries. Such legal suits can rapidly cascade into interlinked damage claims where Company A will sue Company B, which will sue Company C, which in turn will seek compensation from Company A.

• Neglecting Warranties: There are many firms that will offer a cure for the potential Year 2000 malfunctions. A hard-pressed computer executive will have the incentive of taking the easy way by accepting a bid quoting a firm price for taking care of logic malfunctions that involve the calendar. I have looked at some of these bids and find that they lack warranties and avoid independently verifiable safeguards. Budget estimates based on such bids are not worth much, because they do not cover the eventual litigation.

• Misjudging Interoperability Testing: Everyone is concentrating on testing individual programs and applications, but the problem exists at a higher level. Just consider Application X that feeds Application Y, which is also dependent on Application Z. For instance, the world's thousands of telephone companies depend on each other for monthly revenue reconciliation of charges for each phone call passing through their switches. Even though each phone company may be able to bill its customers for local charges, it will find it difficult in the remaining time to test if the transactions originating from others will integrate with their revenue accounting systems.

• Forgetting about Consequential Costs: In the rush to meet the immediate Year 2000 deadline systems executives will make many imprudent concessions, such as deferring essential maintenance, compromising information security through unmanageable outsourcing and upsetting the salary scales by paying ransom rates. In due course all of these liabilities will have to be paid for.

• Counting Dormant Applications: There is an enormous amount of code in the current inventory that serves no useful purpose and should have been junked a long time ago. Maintenance programmers have every incentive to keep old routines in place, just in case their new fixes blow up. I have just obtained good data from a study of fifty mainframe computers. The active library contained only 40% of the code. Unused code was 40% of the inventory and another 20% of the code was suspected as non-functioning.

• Counting and Double Counting Code: I was amazed to find that some of the Year 2000 fix estimates include in line counts the program declarations, logic comments and identical library routines. Year 2000 contractors are delighted with this and explain that all that is accounted for in their low bid per line. Such a practice, highly prevalent in the public sector, serves no other purpose than to further confuse the reliance one can place on any claims about Year 2000 costs.

What is the Expected Cost?

1. All Year 2000 estimates so far exclude the enormous amount of home brewed code that has been placed into workstations and local servers by casual programmers. That now accounts for almost a quarter of all of the U.S. function points. It also represents a potentially costly diversion of business talent, such as engineers and analysts, when it becomes apparent that some of these applications are feeding inconsistent information into computer networks. With an estimated 40 million function points in this category that may need fixing and something like $600 costs to fix a function point this adds up to $24 billion.

2. The total U.S. inventory of professionally managed code that requires fixing is about 100 million function points. That would consume about six million person months of effort.

3. The capacity of the U.S. software staff to get the Year 2000 task accomplished depends on the number of qualified persons as well as the amount of available time. This is where I am getting conflicting opinions. Capers Jones is basing his estimates on a software staffing population of 1.5 million. Howard Rubin tells me that only about a third of that number is qualified to perform microsurgery of legacy code. How many off-shore programmers can be mobilized to help out is anybody's guess.

   The price for identifying, fixing and testing professionally managed U.S. software to get it over the Year 2000 deadline comes out to over $70 billion. To that one must add up to $60 billion for database authentication and repairs, $10 billion for test library development and repairs as well as $10 billion for post Year 2000 remedial work to correct errors from hastily executed patches. In addition to all that, getting the job done in the remaining time is not feasible.

4. There will be considerable cost incurred for additional hardware for testing and parallel running of applications. Many of the upgrades will be also necessary to take badly repaired applications and make them run faster. Chalk up another $20 billion.

5. The largest unknown expense for the Year 2000 disaster is litigation for negligence. Capers Jones estimates that as $100 billion but notes that this number could be much larger. I have just finished testifying as an expert witness, for the defense, in a Federal Court jury trial where a prominent outsourcing firm was sued for alleged negligence. This experience has convinced me that a popular backlash against excessive computerization could make the litigation numbers exceed anybody's imagination.

6. The public sector accounts for 26% of the total function points in the U.S., with 22% of that concentrated in defense. The most damaging Year 2000 headlines may show up as a national security incident involving loss of lives or as political embarrassment. The government cannot be sued for negligence or incompetence but the electorate can surely take out its anger on what they perceive as mismanagement by the professionals with deep pockets.

7. One should also bear in mind that the estimated U.S. resident code makes up only 16% of all of the function points on the planet. One cannot necessarily obtain the global costs by taking a ratio of the estimated U.S. damages. However, it is safe to say that the widely quoted estimate of the Year 2000 global expenses approaching $600 billion is too low.

Management Implications