|
Steve Heller is a y2k programmer. He describes roadblocks in any organization to the repair.
Sadly, his link is dead. But his insights are still useful even though his link disappeared.
* * * * * * *
The people responsible for these defective programs can't really claim that these problems are beyond their control; after all, the fact that the year 2000 was coming has been known for quite some time. Given this, surely the companies that are affected by this problem will have everything fixed by January 1st, 2000. Won't they? . . .
I'm afraid that's not going to happen. The first reason is that, as I write this in 1997, many companies haven't even started working on the problem! How did such a vital task get put off until it's too late? That's easy to explain. Pretend you are a reasonably competent manager working for Amalgamated Conglomerate. Here are some of the major characteristics of the project we need to do:
1.Its success is absolutely essential to the survival of the company.
2. It is mind-numbingly boring, tedious work, which implies even higher turnover than usual in software projects.
3. It is completely invisible to the customer, who has undoubtedly requested a_number of new features that will have to be postponed to work on this project.
4.The skills learned are completely worthless when the project is over.
5. The deadline cannot be postponed by even one day.
Now I want a show of hands: Who would like to lead this project? As I suspected, I'm not likely to get very many volunteers.
But why should fixing these problems be so difficult? All we have to do is to change the date fields to use four digits rather than two for the year portion of the date, and change all of the code that refers to those date fields. How hard could that be?
Much harder than it would be if modern software design rules had been applied. The problem here is that everyone wrote their own date calculation routines, and used these date fields throughout their programs, often without documenting how they worked or where they were used. Some of these programs are thirty years old, and the people who worked on them are long gone, if they're even still alive. The only way to fix these date problems is to go over the code, line by line, searching for any reference to dates. Once each such reference is found, it has to be fixed. Unfortunately, the chance of introducing a new error when fixing an old one is not negligible; in fact, it can be quite high. This means that extremely thorough and careful testing is needed to try to ensure that new errors haven't been introduced in this process.
|