In an industry so accustomed to looking forward to the "new new thing" (to borrow from writer Michael Lewis), bit rot could bring your company's operations to a grinding halt. Every reader of this column has bit rot festering in their infrastructure. Some prime examples are millions of lines of legacy code that have operated smoothly for decades and then one day just don't work. Often this happens because obscure, latent code embedded deep within a strategically important legacy application doesn't play nice with new software you are installing.

Young programmers often make fun of bit rot. But according to Cerf it's no laughing matter, particularly when your firm has no tech workers with the 20th-century skill sets who can dive deep into the problematic code to correct it.

How bad is the labor side of the bit rot problem? It's a hidden consequence of the coming Baby-Boomer retirement brain drain. The older workers in this group (now in their midfifties to midsixties) started their careers programming in Unix, Cobol and Basic. The younger ones (in their midforties to midfifties) worked with DB2, VisiCalc and MS-DOS.

Unless you are a relatively new start-up company, I can guarantee you that legacy code written in now little-used languages is running and running well in your enterprise. But it won't run forever.

The blogosphere seems to have settled on a three-part attack to conquer bit rot. First, determine just how much of your company's critical applications and operating systems run on legacy code. Next, take a suggestion from Cerf and ask yourself how accessible the really critical legacy code is. And finally, retain or recruit workers with the skill sets to make your 20th century code run efficiently in the 21st century.

Do it now, or watch your infrastructure fall apart bit by bit. Or maybe faster.