Mike reminded me of the task we took on mid‑year in 1997, 27½ years ago. If I recall correctly, that’s when the IT department we worked for got serious about New Year’s Day 2000.

This was an outgrowth of our disaster preparedness project. Some context: large corporation, HQ and most of the manufacturing in New Jersey, the rest in Memphis. The good news: the IT center was in Memphis where I lived. The bad news: Memphis is on the eastern edge of Tornado Alley’s range from Oklahoma across central Arkansas. Most of the twisters seem to dodge north or south around the city, but you never know.

True story — The Memphis plant had an Uninterruptible Power Supply (UPS) facility housed in a separate structure behind the computer room. The UPS held a ton of lead‑acid batteries and power conditioning equipment, plus an automated diesel generator outside. One thunderstormy afternoon a lightning bolt took out the power line to the building. Everything went dark. The UPS kicked in within milliseconds and our IT equipment kept running just fine — until a second lightning bolt took out the generator. The utility’s linemen, bless ’em, had us powered back up a few hours later and just minutes before Management’s deadline for declaring a disaster.

“Declare a disaster” means you kick over to your spare copy “in The Cloud,” right? Not in those days. The Cloud (which really is market‑ese for “somebody else’s computer”) isn’t a viable operation without telecomm speeds a hundred times faster than the comm lines we had in the 1990s. Back then Disaster Recovery (DR) was a multi-step process:

• Backup your essential programs and data onto tape
• Truck the tapes to a secure distant storage vault
• When/if a disaster is declared, move operations to an offsite DR center that offers comparable IT facilities (computers, data storage, network connections, etc.)
  • Truck the tapes to the DR center. People, too, if necessary.
  • Read the tapes onto DR center storage.
  • Pray that your backups in fact had all the stuff you need and that the data’s sufficiently up‑to‑date for business requirements.

Clunky, huh? But the process gave us practice in cloning our systems and thinking about risks. That’s where our Y2K prep started.

The real “Y2K problem” wasn’t the 2‑digit‑year design flaw, it was the impossibility of doing reliable date logic or calculations when the dates in question might be in either century. Did “X” happen before or after a deadline? No way to know when “12” is all you’ve got to work with. Fixing the problem was a multi‑prong challenge:

• Revise the data structure to hold a four‑digit year.
• Revise the stored data with the right four‑digit year numbers.
• Revise the programs that handle the data but…
• Don’t break the programs that you revise.

Most of the program updates weren’t particularly challenging, it’s just that there were so many of them. Some enterprises knew their own software well enough that they did that work in‑house. Others shipped the work overseas, a tremendous boon to India’s fledgling software industry. Still others said, “Our competitive advantage is our product line and marketing team, not our home‑grown programs. We’ll convert to an industry‑standard replacement even though we’ll have to change how we’ve been doing business.”

Whichever strategy was chosen, the devil was in the testing. No way could new code or data structures be checked out with live data on our production system.

We needed a testbed, a sandbox, “System 2K,” whatever you want to call it, that was isolated from the live systems we made our money from. It had to have no‑leaks portals for programmer access, code revisions and artificial test‑case data. Most importantly, its system clock had to be adjustable to any future date.

That’s where my team came in. Using what we’d learned from our DR practice runs, we cloned our running system and bolted on some tricksy infrastructure. Don’t ask about technical details, that’s a quarter‑century ago and I don’t remember them.

But I’m proud to say that New Year’s Day 2000 was boring.

~ Rich Olcott

• Thanks to Mike Newsom, whose comment inspired this post, and to Bob, Susie, Ralph, Tom, Doug, Mick, Don, Roy and the rest of the project team.