Make your own free website on Tripod.com
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.

Gary North's Y2K Links and Forums - Mirror

Summary and Comments

(feel free to mail this page)


Category: 

Too_Late

Date: 

1997-01-03 00:00:00

Subject: 

Warning: It Always Takes Longer Than Planned

Comment: 

This man says it honestly: programmers underestimate time. Professional surveys confirm him. Large-scale system alteration projects are late at least 85% of the time.

____* * * * * * * * *

Date: Mon, 30 Dec 1996 21:14:17 -0500 From: John Neal

I believe your programmer friend may have over-simplified a few of the technical aspects, but basically, he is correct.

1. From a technical point of view there is absolutely nothing complex about the Y2K problem. The solution to any given incident would be worth no more than 5 points on an entry level coding course in any computer language.

2. There really are no problems with the programs per se. They work absolutely correctly with the data that is currently fed into them. The problem is with the data and must first be solved there. Of course, when you do, it is then necessary to change the programs since they are the slaves of the data they serve.

The Y2K problem is one of management and housekeeping. Trying to change everything, all at once, all across the shop/industry/nation/world is what makes Y2K such an intractable beast.

Think of some simple activity such as honking every automobile horn in America precisely at midnight on New Year's Eve. Technically, it's a no-brainer--push the center of the steering wheel and the the horn blapppps. But, how do you insure that everyone cooperates? How do you guarantee that not one single car will have a dead battery, or a corroded horn contact, or a driver too intoxicated to read his or her watch? How do you get all the watches synchronized? What about all the cars in the wrecking yards? What about horns in auto parts stores, not installed in vehicles yet? Do they count as _horns that must honk?_ What about new and used carlots? What about local noise ordinances?

Okay, so the preceeding was a very silly example--yet maybe it is easier to relate to for a non-programmer.

Remember one thing, in the entire history of programming, it has never been recorded that a programmer _ever_ accurately estimated the time it would take to fully implement a program into general use. They are very good about how long it takes to write programs, somewhat good about how long it takes to unit test a program, and haven't the faintest idea how long it takes to document, train user base, roll out to operational units, verify completeness and turn up in daily use. The part they are good at estimating usually turns out to be about 15% of the total effort, and more like 10% of the total time.

This is not intended to be a slam at programmers, the other activities are generally not their responsibility and therefore there is no good reason for them to have any expertise in the time and effort involved. (And besides which, I are one:)

So in short, yes in general, the methodology makes sense; and yes, the elements listed are the very ones which will require $300 billion to perform in the United States within the next three (gulp) years.

John Neal President, Neal Laboratories, Inc.


Return to Category: Too_Late

Return to Main Categories

Return to Home Page