Y2K: 10 years later

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 $345 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.

Another lesson, says LogLogic's Roth, was that systems last longer than we think and need to be ready for the future. "You always have to be future-proofing the software you write, the hardware you build," he says.