Where have all the Y2K bugs gone?

From GartnerGroup

Perhaps the most-asked question we have received since the year 2000 date
change occurred is why more problems have not been reported. One reason is that
the Year 2000 problem is not about only the boundary period and therefore must
be monitored throughout the year. Another factor is that organizations as a
result of their spending are getting what they paid for: operational software
and hardware.

Event: On 1 January and 2 January 2000, GartnerGroup year 2000 analysts were
deluged with media requests for interviews. In that period, the most-asked
question focused on whether the year 2000 problem was a "hoax" because
so much money was spent but so few problems were reported.

First Take: Several factors explain why incidents of reported
year-2000-problems have been relatively low since the date change occurred:

Problems have already been reported publicly – A number of problems were
reported, from issues in nuclear stations in Japan to minor aviation-related
problems in the United States. Fortunately, these problems were correctable and
their severity was minor. Said another way, they have been nuisances. However,
the "myth" that no problems were reported is just that. Most problems
will go unreported publicly – Most organizations are not required to publicly
report year 2000 problems that they find and fix internally. Most year 2000
defects that have been found and fixed have not come to the public's attention -
nor will they, in the coming days, weeks and months. Although some decry the
"secrecy" of such fixes, no regulation forces such reports. In most
cases, it is not in the organization's best interest to publicly report failures
of any severity.

Many technology asset types have not yet been executed – Over the 1 January
2000 midnight boundary, embedded devices and some hardware, software and
middleware were executed. Although certain applications were also executed, this
did not occur across-the-board. However, by the end of the first full week of
January 2000, daily batch cycles for 31 December 1999 will be completed, as will
week-, month-, quarter- and year-end processing for 1999; offline systems will
be brought up; and batch cycles for the first daily run of 2000 will be
executed. This period will show how well application remediation efforts were
performed.

Problems will be reported through the year – Previous GartnerGroup research
noted that only 10 per cent of problems would occur in the two-week period
around the boundary, and that 55 per cent of all problems would be noticed
through 2000. A constant report of daily problems likely will not emerge:
"spikes" of defects will be noted on the first daily, weekly, monthly,
leap year, quarterly, semiannual and annual cycles. Software will break when
transactions are run, and organizations must ensure they understand when and
where date-related transactions will execute.

Money was spent and problems were fixed – Most organizations began their
year 2000 work in late 1997 or early 1998 in real terms. Most organizations
spent considerable resources (up to 40 per cent of their IT budgets) on year
2000 remediation. In addition, the usual application development project has as
little as 10 per cent to 35 per cent of its project budget spent on testing;
year 2000 programs spent up to 75 per cent of the budget ensuring that
interrelationships among software components worked as specified.

As we have long stated, the year 2000 date change would be a no-win situation
for organizations. If they spent huge sums correcting year 2000 problems and
major failures occurred, they would have spent too little. If they spent
exorbitant amounts and experience few (or no) major problems, then the
perception is that too much was spent! We prefer the latter. Substantial amounts
of money have been spent, and in this case, it appears (at least initially) that
organizations are getting what they paid for: operational software and hardware.