Make your own free website on
Recommended Resources Offshore havens, asset protection, global investing and other useful techniques.
The Year 2000 Bookshelf Books to help your evaluate the Y2K problems you face.

Gary North's Y2K Links and Forums - Mirror

Summary and Comments

(feel free to mail this page)




1997-10-03 23:44:44


The Task's Complexity Described



Randall Bart has been programming in Cobol for 20 years. He is very pessimistic about fixing y2k. Testing the millions of fixes is an even bigger problem.

* * * * * * * * *

Simply put, the Year 2000 bug isn't a single bug, it is literally millions of little bugs. The Legacy is huge, and every program must be checked to see if it is compliant and many, many programs will require some change. As I write this there are about 820 days left. Even with software tools to assist in the conversion, there aren't enough programmers to fix the bugs.

But let's assume that the Programming Fairy brings us enough programmers to work on every program. Unfortunately, that's not enough. Even the best programmers write bugs that they only find by testing. Thorough testing of Y2K requires setting up a time lab: A shadow operation with time machines (computers with their dates set ahead), with data entry operators entering transactions, and operators running the daily programs. A time lab must simulate more than a full year to catch the subtle date dependencies in a system. This is a very resource intensive test procedure, very few companies have the equipment and personel to do it right. Furthermore, most companies are regularly exchanging data with other companies, so a thorough test would require all those other companies to have time labs running with the same dates. And those companies interface with other companies, etc. A project of this scale takes many years. And even when testing is done right a few bugs slip through the cracks.


Return to Category: Programmers'_Views

Return to Main Categories

Return to Home Page