At a talk earlier in the week I was asked if the millennium bug fixes should be cleared out. The question was asked while talking about clearing out dead and commented out code. My response off the top of my head was yes, but I’ve since reconsidered. The answer, of course, is not that simple.
Firstly, the question wasn’t about removing commented out or dead code. Secondly, what the millennium bug fixes actually fixed may still need to be handled.
But, perhaps I should back up a little bit. The system the question was about was a COBOL system that’s been around since 1969. A lot of work was done to secure it for the turn of the millennium, and probably for good reason. If you weren’t around or wasn’t a programmer during the 90s, you may not be aware of the scope of terror system owners felt. The fear was spun further by media on a daily basis as New Year 1999/2000 approached. Headlines blasted out that salaries would fail to get paid, power-plants where likely to blow up, ships would run into docks while mooring, cars would stop working, the dead would rise again… On it went, and billions of dollars were thrown into fixing the millennium bug.
And so the dreaded turn of the millennium arrived… And nothing happened. Perhaps it was the fact that probably every programmer in the world had been working overtime to build in checks that abbreviated dates (i.e. 18/9/66 would be interpreted as 18/9/1966 rather than 18/9/2066). Or perhaps it just wasn’t that big a problem.
So, my spontaneous answer was yes, but, as I mentioned earlier, the answer is not so simple. What needs to be considered, of course, is
- are there tests to help verify that the changes don’t break the system’s functionality?
- can situation still arise that the millennium fixes were built to handle?
- what is the size of the effort to remove the millennium bug fixes?
- what is the benefit to the code and to the business in removing the millennium bug fixes?
While I still think that some millennium bug fixes should be refactored out of old systems (indeed all unnecessary code should be), there are considerations to be pondered before doing that.
Conclusion
Before any refactoring is undertaken, effort should be spent to ascertain that the refactoring can be made in a safe way and that the refactoring doesn’t break the system. Without automated tests and a thorough understanding of the system and its data, it is a very dangerous undertaking that should be addressed carefully.
