Where have all the Y2K bugs gone?

CIOL Bureau
New Update

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


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.