| Recommended Resources | |
|---|---|
| Cyberhaven.com | Offshore havens, asset protection, global investing and other useful techniques. |
| The Year 2000 Bookshelf | Books to help your evaluate the Y2K problems you face. |
|
(feel free to mail this page) (Links to documents appear after the summary.) Estimates vary as to what percentage of a y2k repair project must be devoted to testing. The low estimate is 40%. The high estimate is 70%. It doesn't matter. The testing won't be done by more than a handful of organizations. Here's why. First, hardly any organization will ever finish the actual code repair. They will not have anything to test by the time the deadline for testing arrives. In his widely respected report, Capers Jones says that any organization that had not begun its code repair by October, 1997, will not complete its project. By October, 1997, well under 20% of the Fortune 500 corporations had begun repairing their code. The rest of the world was even further behind. Second, parallel testing is mandatory for large systems (10 million lines or more). Data must be fed into the noncompliant machine and the compliant machine simultaneously in order to make sure that the compliant machine handles the data properly. Such testing should go on for weeks or months. To run these parallel tests, an organization needs excess mainframe computer capacity of at least 100%. This includes data storage. It also needs a second team of programmers. Yet modern mainframe computers are operated on a 7 x 24 basis: seven days a week, 24 hours a day. The only time a mainframe computer is not running is when it is down for maintenance. Third, there will be coding mistakes. These will crash the repaired system or else disrupt it. These buggy systems must then be checked, the errors repaired, and the system re-tested. The system may fail again. Time runs out. Fourth, almost every organization has promised to be at the testing stage by December, 1998. Again and again, we see this deadline mentioned in public relations hand-outs and PR letters to clients. Ask yourself: Are all computrer systems equal? Are all programming teams equal? Can they all complete the job in the same month, no matter when they got started? It's nonsense. This preliminary deadline date is the product of lawyers, who have warned managers and directors that if they do not officially aim at December, 1998, they may be accused retroactively of not doing "due diligence" after the repair task fails to meet the Year 2000 deadline. They will then be sued, possibly even personally. (They will be sued anyway, assuming the courts are still functining and the government has not extended immunity to y2k-afflicted organizations, especially government organizations, as Nevada did in July, 1997. There is too much money at stake.) If you are told by some official that his firm will be at the testing stage in 1998, write back and ask him the name of the mainframe time-leasing firm with which it has a contract, beginning the day after the first stage of the repair is completed. If the firm has no such written contract today, then either management must be planning to have available in-house an extra 100% of today's computing capacity or else management has no idea what the company will be facing in 1999. It's Catch-22. If all organizations that say they will be ready to run the tests in early 1999 actually meet this deadline, then (1) there will be no excess computer capacity available to run them, or (2) there will be excess capacity only because hardly any firm has met the deadline for testing. I'm betting on the latter.
|