Was the Y2K Millennium Bug fear overblown?
"I think people felt duped because the world was predicting a disaster," Quinn says. There were even predictions that cars would stop running because of engine clock problems, he says.
"My recollection is that probably 70 percent of that concern turned out to be unfounded -- but you had to do the research anyway. You couldn't take a chance" in mission-critical environments like financial services and health care, Aaron says. He says he could not recall an actual Y2K problem that could not be fixed in five minutes. "My opinion is it was a quiet day because people put the proper focus on it, did the right amount of due diligence, and [did] the work that needed to be done."
Concurring that due diligence took care of the problem, Chip Ahlswede, who worked for the U.S. House of Representatives at the time checking on Y2K compliance, says it was better to be safe than unprepared. "I think it was the preparation thing," says Ahlswede, who worked as a subcommittee clerk. He now is principal at Regal Strategies, a political consulting firm. He remembers Y2K's mild impacts. "As far as the government, there were a few systems that had glitches after the fact, but obviously no missiles were launched," Ahlswede says.
"The high publicity it garnered ensured that everyone took care of it," recalls Micro Focus' Coker. Corporate managers were afraid of getting sued as a result of Y2K problems, he says.
Another IT official, who worked at Sun Microsystems at the time, disagrees sharply. "I don't think that IT should look back and say, 'Hey, Y2K was successful because nothing happened,'" says Bill Roth, who is now chief marketing officer at LogLogic, which provides security and event management. He had been a Java marketing manager at Sun Microsystems during Y2K. "It is unlikely that anything would have happened other than people having their birth dates stated incorrectly or checks being predated by 100 years."
Although he stresses the Y2K issue was overblown, he acknowledges there were legitimate reasons to be concerned: "The problem was about poorly written, date-based mainframe applications." Still, "the power grid stayed up, our trading system stayed up, and while a small amount of it was due to the diligence of people cleaning up Cobol code, it's unlikely that anything would have happened in any event," Roth says.
But Aaron points out potential mishaps. "You had to look at every single system assuming it was going to break," he says. Potential existed for mishaps such as two parties sharing a financial trade and one party seeing the date wrong, voiding the trade, and creating a massive number of trade breaks among financial institutions. "You would have wound up with customers that think they made a trade because they called in an order but the order never executed," Aaron says.
As awareness grew of the Millennium Bug, it was unclear how pervasive it was. And that meant that programmers had to review lots and lots of code to see where the problem might exist. The effort to prevent a Y2K disaster swung into earnest about two years before Dec. 31, 1999, Aaron notes. The result most of the time was that software did not need any changes to accommodate Y2K, Aaron says. Systems either already were set for the 2000 switch or just needed a simple work-around.
Many systems, such as embedded systems and chips, did not fail from Y2K because they did not even run on Julian calendars, says J. Greg Hanson, executive vice president at technology services company Criterion Systems: "The clock on the computer chip is not based on calendar time." Y2K was mostly a problem associated with business software, says Hanson, who at the time was chief software engineer for the U.S. Air Force and led its $US345 million Y2K program.
Y2K's legacy: Better disaster planning and documentation
Despite the debate over how serious the Y2K problem would have been had companies not invested so much time examining code for the Millennium Bug, it's clear that the IT industry did learn some lasting lessons, Aaron says. These include doing continuity and disaster planning and documenting systems, he says.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.