Post-2000 Errors: Experts Warn of Aftershocks
Once you open up your code to Year 2000 fixes, it's open to new defects that testing may miss. In fact, the appearance of newly created defects in software brought about by changes made during Y2K repair may cost U.S. companies an additional $98 billion to $188 billion to fix, or about 31 percent of the money already spent on Y2K renovations, one expert now warns.
This phenomenon -- the Y2K aftermath -- occurs when a "seemingly innocuous change to a software program brings about unwanted side effects that result in the creation of new defects," says Dan Galorath, president of Galorath Inc. (El Segundo, Calif.). "This is especially common in older applications -- the very ones being renovated to fix the Year 2000 problem -- because they were written in original languages to run on slower machines with less memory and disk space than state-of-the-art hardware."
"Statistics show that in Year 2000 work, the best programmer alive will typically make three errors for every 100 modifications that he or she makes to the code," notes Steve Angelo, VP of marketing for Reasoning Inc. (Mountain View, Calif.). Even the most comprehensive testing process may miss some of these non-Year 2000-related defects.
"The conversion process creates or recreates defects," agrees Lee Mulder, president of Into 2000 (Jasper, Ga.). "Testing won't necessarily guarantee you a clean system when you get into production," he notes. "Testing involves samples, where you're not looking at everything. You can test all you want, but still have to hold your breath when you put your code back into production." Into 2000 recently announced an agreement with MKS Inc. (Waterloo, Ontario) to bundle MKS' SDM TestSuite with Into 2000 to provide testing and inspection capabilities to AS/400 systems. "When you test an application, you only test things that were repaired. You need to also test for new defects that were created," says Mulder. "Especially with windowing, when adding code, you have a chance of adding a defect."
The way to address potential conversion errors is an organized process to conversion and testing. A compliance policy that tracks changes from conversion to testing may help catch potential defects, says Angelo. "If you used a windowing remediation strategy rather than a date-field expansion strategy, why waste time looking for errors that went to an expansion strategy?"
Inconsistent remediation may also cause applications to fail, Angelo says. For example, a windowing solution in one application might have a pivot date of 50 [all dates greater than 50 are in the 20th century, and dates less than 50 are considered 21st century], while another will use 35. "Incompatible windowing routines that will cause applications to crash, fail, or generate the wrong result," he warns.
In quantifying the Y2K aftermath problem for a major client, Galorath engineers used SEER-SEM, a software estimating application, to determine that the company needed to renovate 682 different systems, comprising over 44 million lines of code. Their analysis predicted that after the massive effort of renovating and testing their software, they would still have to contend with more than 8,000 new defects in their renovated systems.
Still, many aftermath defects "will not be discovered until the systems are in full operation," Galorath says. "Some problems will be immediately obvious, like leap-year confusion. But most will be side effects that are unrelated to Y2K issues. Systems that are supposed to run continuously, for example, may stop intermittently. These problems will require debugging and repair while still in production -- the most costly maintenance possible."
According to the SEER-SEM analysis, about 35 percent of these defects can be detected and repaired within the first year. The more subtle problems will show up during the second and third years of operation. Galorath estimates that the top 500 U.S. corporations will have to deal with over four million new defects caused by Y2K repair work. "But that is just the tip of the iceberg: our analysis does not quantify financial losses caused by the malfunction or failure of mission critical systems," he warns.