- including mundane tasks such as upgrading documentation. Untold new problems caused by introducing changes into old buggy code have been averted, and the total payoff could well dwarf the estimated expenditure of $500 billion.
- Another important byproduct has been the maturation and more widespread utilization of automated regression testing. Most test tool vendors and test consulting firms experienced a surge in demand and revenues that have led to faster product improvement than would have occurred otherwise.
- Fear is a great motivator. Testers who had struggled for years to gain commitment and support suddenly found the budget floodgates opened.
Like a doctor saying that she needs a multimillion dollar medical device
or else the patient might die, smart testers tied everything on their pent-up wish lists to Y2K, such as the need for expensive automated test tools.
- Fixing problems is the tip of the iceberg; regression testing is the bulk. Organizations that undertook reasonably prudent steps found that the effort to retest after changes to old code was often three to five times bigger than the effort to make the changes.
Unfortunately, many things remain the same:
- The law of software entropy (some call it software rot) remains in effect. Reliability of software degrades over time, as changes introduce a gradual accumulation of unintended bugs. Entropy relentlessly continues.
- In my observation, there is only minor progress on the most important payoff we could have hoped for. Organizations have not faced the root causes or significantly changed the convenient bad practices that made Y2K so dangerous in the first place: entangled system designs, hasty changes, and inadequate regression testing. It's a little like someone going to a dentist for an intensive and painful deep cleaning, then lapsing back into lackadaisical dental hygiene practices.
- The problem has not gone away. Myriad date-related incidents lurk waiting for the right moment, such as the resetting of the Unix clocks in 2038. Everybody is confident that all the old Unix code will be replaced well before then. That's what we thought in 1990 about the Y2K bug.
Finally, some lessons learned:
- On any project where attorneys predominate, the test documentation seems to double and the project costs triple, and the testers' rates of reimbursement look exceedingly modest. In some organizations, every third member of the Y2K team seemed to be an attorney.
- Be careful what you predict. Some industry pundits became carried away in their pronouncements of gloom and doom and looked ridiculous after the fact.
- Don't expect the press-or technical professionals-to get the story right. We can't predict where the bugs will be or precisely how much testing is enough. Given these uncertainties and the acknowledged huge degree of risk, the effort that was viewed as overkill turned out to be a prudent, justifiable response.
- Don't expect to be rewarded with the key to the executive washroom. In a survey conducted in mid-2000 by Howard Rubin, seventy percent of the information systems professionals who were significantly involved in Y2K projects were dissatisfied with their rewards. They felt that the bonuses, retraining, and new positions promised by their organizations in return for their Y2K efforts had not materialized. A mere two percent thought their rewards were above expectations. Says Rubin, "In general, Y2K folks have gotten few rewards. While digging in on Y2K, many missed the e-Business boat. And because there was no Y2K bang, industry executives gave them no bucks. It's sort of a paradox because they should have gotten lots of bucks for no bang."
Now that Y2K is well behind us, we can forget about all this date nonsense until the