|
Capers Jones describes the main programming approaches to dealing with the y2k. The best one -- date expansion -- is no longer possible: it's too late.
There is no agreed-upon alternative.
Will the various approaches integrate in 2000? No one knows.
* * * * * * * * *
There are a number of strategies for fixing the year 2000 problem. But it is now 1998 and there is no longer time available for changing date fields in software and data bases from two-digit to four-digit formats. A variety of "masking" approaches are being used which do not actually change the date format, but utilize external, outboard software tools to convert dates entering and leaving the application. Following are brief discussions of major year 2000 repair strategies:
Date field expansion: Expanding date fields from two-digit to four-digit form is the "classic" method for solving the year 2000 problem. This method provides a permanent solution, but has proven to be costly and difficult for many applications. Sometimes dates are indirect and hidden. For example, dates may be embedded in product serial numbers such as "1234984321" where digits five and six show the year 1998 embedded in a 10 digit serial number. If date field expansion is the primary method used, it takes between 36 and 40 calendar months to completely convert all of the dates for a major company, so unless you started in 1996 there is no longer time to use this approach except for a few key applications.
Windowing: The windowing method establishes a fixed interval time period, such as 1915 to 2014, and uses external program logic to deal with all dates within that period. Assume that your window runs from 1915 to 2014. Dates below the mid point of the window such as 03 or 10 are assigned to the 21st century as 2003 or 2010, while dates above the mid point such as 97 or 98 are assigned to the 20th century as 1997 and 1998. Windowing for a portfolio can be finished in roughly 18 calendar months, so this has become one of the popular methods with late starters. However, windowing exacts a performance penalty and assumes that everyone using the data or the application knows about the existence of the windowing routines.
Compression. . . .
Encapsulation. . . .
Bridging. . . .
Data Duplexing. . . .
Object-code date interception. . . .
Other alternatives for dealing with the year 2000 problem are also running out of time. Replacement with commercial packages is an option, but this approach does not work for custom software. It is far too late to build major replacement applications. Therefore, now is the time to start contingency planning on how to deal with date problems that won’t be fixed in time.
Incidentally, in the entire 50 years of the software industry there has almost never been a major software application released to users where 100% of the latent errors were found prior to deployment. The current U.S. average overall is about 85% of defects are removed and 15% get deployed.
There are roughly 36,000,000 applications running in the world that have year 2000 date problems in them. It is very naïve to think that 100% of these will be repaired in time. It is also naïve to think that for any specific application that 100% of the year 2000 date references will be found and repaired.
The "best in class" removal efficiency for coding errors is less than 99% circa 1998, and the average is below 95%. While year 2000 specialists with automated search engines might achieve 99.9% defect removal efficiency, there is no reason to believe that ordinary programmers will exceed historical average results of roughly 95%. There will be year 2000 problems present at the end of the century, and hence contingency planning is needed right now.
|