| |
|
August 3, 1998
More Y2K lessons
One of the most interesting aspects of the Year 2000 (Y2K) problem is that even this
close to the big day and with several years of programming already invested in fixing
noncompliant systems, I can still find almost any shade of opinion regarding what will
happen at the witching hour. Apparently equally credible industry observers forecast every
possible Y2K outcome--from minor irritation to something approaching the end of
civilisation as we know it.
Who do I believe? I'm not too worried about safety-critical embedded systems. Midnight,
31 Dec 1999, is not likely to see me travelling anywhere by plane, but the Y2K issue
wouldn't stop me. Likewise, I have few fears about other transport systems, medical
monitors, and the like. For the most part, those systems will have stand-alone software in
which date dependencies will be relatively easy to identify and for which any necessary
code updates should have been installed by or during 1999. And, at this point, there has
been adequate publicity to ensure that the right questions will be asked of such systems
before the Y2K date.
One argument that I find convincing, though, is that problems are likely to surface in
large suites of commercial software--for example, the systems that banks, airlines, and
phone companies use for control and billing. Why? Because some of that software reportedly
dates back decades and has been modified and patched by countless programmers as systems
were extended and new facilities added. Further, bits of code have been taken from one
program to run a similar function in another program.
When you consider that such systems will interact, exchanging date and time
information, some of the most subtle opportunities for Y2K crashes come to light. Many
such systems have been written in Cobol. For many months now, programmers with Cobol
experience--sometimes from way back--reportedly have been making small fortunes in
consultancy fees for simply going through commercial code and documenting what it does.
Did all of the programmers who worked on such code over the years carefully and accurately
document every fix and patch they wrote? What do you think?
Does this scenario remind you of anything in our domain? Is this not design reuse in
action, albeit of an unplanned and haphazard style? There is no shortage of voices telling
us that we must implement reuse on a significant scale or our complex next-generation
designs will never be completed on schedule. But if we don't establish the right
methodologies now, in the early stages, we shall only be storing up trouble for the
future.
Just keep in mind those programmers, gingerly picking their way through layers of
commercial code, almost afraid to touch any part of it in case their changes crash the
system in some unexpected way. Also, considering that commercial software has grown in
complexity perhaps an order of magnitude (or two) over recent years, we are actually
setting in place methodologies to handle complexity growth many times that. The conclusion
should be obvious: We must get it right while we have the chance.
|
