Y2K 10 years later

It seems like just yesterday many of my friends and colleagues in the federal government and industry were spending New Year’s Eve in Y2K Command Centers watching with great anticipation as the ball dropped in Times Square that New Year’s Eve, 1999.

I had been chief technology officer at Telos for two and a half years and thought back to when I arrived in the spring of 1997. Like most companies, Telos had not taken any significant action regarding the potential impact of Y2K, or the “Millennium Bug”, as it was often called.

I was keenly aware of the issue, as I had just retired from the U.S. Air Force, where I had been in charge of the Air Force’s Year 2000 program. In that capacity, I had worked with software engineers Air Force-wide and briefed the chief of staff, secretary of the Air Force, and the deputy secretary of defense on the issue from the ground up. We began that effort in earnest when the federal government received a grade of “D” on the first Y2k report card that Rep. Stephen Horn (R-Calif.) issued.

Having taken the technology helm of a global corporation that served the Defense Department, I and my colleagues quickly got to work looking at our office automation, production, financial, human resource, inventory and tracking systems, and our entire suite of product offerings. As a result, I spent New Year’s Eve 1999, not in a command center, but at a New Year’s Party and on 1 January 2000, our systems experienced no ill effects as the new millennium dawned.

But this does not mean that it was a non-event or that we didn’t learn a lot from the Y2K experience. Exactly the opposite--many people worked very hard to ensure that our nation’s information systems continued to operate correctly. Moreover, I believe there are some valuable lessons we can learn from the experience.

Thankfully, we didn’t observe the calamity many had predicted. Infrastructure control systems did not fail, military weapon systems were not automatically armed or launched and bank accounts were not wiped out.

The Y2K problem affected systems which perform calculations based on Julian Dates–primarily business systems. Control systems, such as those in GPS satellites, typically use different timing schemes.

Additionally, Y2K was not some sort of software conspiracy.

I was once asked, “How could you software guys let a stupid thing like this happen, with your SEI and CMMI?”—referring to the Software Engineering Institute and its process improvement approach called the Capability and Maturity Model Integration. In an age when mass storage can be had at less than a dollar a gigabyte (a billion bytes), it is difficult to recall -- or increasingly for younger IT professionals, imagine -- a time when memory was so precious that programmers used two-digit dates to conserve two bytes of memory.

People still consider software engineering to be an inexact science, but I believe we learned a lot from the Y2K experience that translated into better quality software and more disciplined development and testing practices. Yes software still has bugs, but when you think of how pervasive it is and the capability it gives us--“I’ve got an app for that”--we’ve come a long way since the dawn of the millennium.

The Y2K experience also produced a unique opportunity for public and private sector to conduct a significant house cleaning with their information systems.

That effort began in 1996 at the Air Force Y2K Program Office and led to the diligent inventorying and triaging of Air Force software systems. It also led to efforts to prioritize systems in terms of mission criticality and assessing which ones could be remediated and which ones needed to be replaced.

From the commercial side, we used the Y2K problem at Telos as an opportunity to transition to state-of-the-art office automation systems. We scrapped our proprietary e-mail and database systems in favor of modern, industry-standard, Y2K compliant systems.

However, despite our best efforts to clean house -- to eliminate legacy software systems -- we might not have done enough. Many legacy systems still remain. I was struck by the statistics at a major technology conference earlier this month when a top software acquisition official briefed us on just how much time and cost it adds to a project to have to build interfaces to the thousands of legacy systems that still exist.

But consider where we might be had we not had to confront Y2K.