Y2K Unintended Consequences

As with all large projects, some things come easy and the end comes hard. It is the last 1% of a project or the proper documentation and testing that proves the project ‘s worth. There can be a lot of hangups in this phase. One such hangup is the law of unintended consequences which briefly states that if a lot of old code that you know very little about is suddenly changed and tested:
1. You won’t know what to test for, since you aren’t the original designer.
2. Even if you do know what to test for, the likelihood that things that are never supposed to happen, but do, in fact, happen , goes up.
3. Beta testing goes on for a lot of computer programs and is valuable, too, due to the buying public can foul anything up.
4. The reasons for the failure of up to 1/3 of everything that was fixed and tested are many, but a major one is people, impatience, and just plain anger at having to wait on a computer.
a. People are inventive, and totally without care with respect to machinery.
b. People are impatient and will not wait on anything, much less, a computer program.
c. People get angry fast at machines if they don’t get instant satisfaction.
d. People make mistakes and then do creative things to try to cover up their dumbness. I don’t know about you but every time I get creative with a computer, it locks up, at best, and won’t play anymore.
e. If you lose data on a computer because it just crashed, do you shake the machine in fury, because you don’t know any better or what. I can’t say that I haven’t done it at one time or another.
5. There is no beta version of y2k around, this is a unique event in history and there will be things happen that under normal circumstances wouldn’t and that’s life. This is also not a one-time event as related problems can and will come up and get the y2k blame put on them. For instance, a typical software issue comes up in 1999 to 2001, and automatically it’s suspect for y2k involvement. Worse it comes up after the y2k problem has been fixed, supposedly, and some manager asks why the programmers didn’t see it and fix it at the same time. Actually, someone could get fired because of this.
6. If you try to fix all the problems at one time how do you test with all the new variables you’ve just created. The standard way to fix anything is to fix one thing at a time and then test so that variable is out of the way, so to speak, then go on to the next. If you fix 40 lines of code without testing what you’ve just completed, you’ve just entered 80 variables into your system. Remember who is going to use this program, Joe Q. “mad dog” Public and he makes mistakes. That is 6400 possible tests and even if only 200 are real possibilities, that is a lot of testing. People have said that there is at least 1.2 trillion lines of code to fix for y2k. That is conservatively 3 trillion tests to do to verify compliance. There is not enough time in several lifetimes to test it all. You begin to see the problem.
7. Quite possibly, y2k will not be the seamless transfer everyone “thinks” it will be.

Hindsight: Cisco is experiencing a ½ trillion downturn that is possibly one effect of y2k. So many companies fixed so many computer systems during 1999 & 2000 that they ran out of budget & potential problems in 2001.