| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Yes, another Y2K issue to worry about: sabotage
(IDG) -- Here's yet another Y2K issue to worry about: Y2K sabotage. I don't want to sound alarmist, especially because there's no evidence it's happened deliberately yet, but it's something else anybody contemplating Y2K issues should keep in the back of his mind. To be sure, there are probably more immediate and pressing issues to worry about first, such as costs, legal issues and staffing shortages. The latter is particularly vexing. In an effort to throw enough bodies at the problem, we've gone to the retirement pool to find those few who still remember how to program in 1970's code. We have also gone to the back of the rack and dusted off the old textbooks in an effort to train a new crop of 1970's cold-war era programmers. Through all of this, we may be letting in a bunch of programmers that may not be ready for prime time.
In an effort to fix the Y2K bugs, many companies have tried to speed up their fix and test cycles (after all, we're not all that far away from the next millennium). The problem is that all this re-coding may be introducing new bugs that are not caught during the initial testing for date compliance. By itself, this should not be a major issue - except that all those programmers rushed into the fray might not have gotten a proper education in overall coding skills - especially if they're dealing with relatively unstructured code that requires more work than simply changing a date. But what about sabotage?In an era of ever-increasing software viruses and "millennium bugs" appearing on the radar screen, we know that there are less than scrupulous individuals out there that enjoy wreaking havoc among both the general public and corporate organizations. This brings us back to the staffing shortage: With companies getting increasingly concerned about Y2K, they might not scrutinize would-be Y2K coders as much as they should. This could lead to "less than scrupulous" individuals being given free access not only the Y2K code, but potentially all the code of company. And since these virus kings are often very skilled and crafty, their millennium bugs may not be easily detected by standard Y2K-only code testing. While there may no longer be enough time (or money) to give re-written code a proper fine-toothed combing, it is not too late to make sure that Y2K staffers are adequately supervised. Unfortunately, trying to limit Y2K staffers to just those code sections that deal directly with dates will be difficult, because it's often not clear where exactly potential problems are located. One possible solution is to separate the Y2K bug location process from the Y2K fix process, allowing one group to test and find the bugs with another group to fix only the code that is affected). In any event, users everywhere need to be aware that if they are not careful, they may find that the "cure'' is worse than the disease. Fred McClimans is CEO of Current Analysis, Inc., a competitive intelligence and analysis firm. You can link to the Current Analysis Web site or reach Fred at fred@ currentanalysis.com.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Back to the top © 2000 Cable News Network. All Rights Reserved. Terms under which this service is provided to you. Read our privacy guidelines. |