On January 1, 2000, the expected worldwide computer breakdown did not arrive. That was a relief. It also made the work behind it surprisingly easy to dismiss.
The images are AI-generated visual metaphors, not photographs of historical events.
Billions of dollars went into preparing for Y2K. Against that expense, an ordinary morning can look like a poor return.
Unless you were one of the people who had spent the previous months making sure it would be ordinary.
I keep coming back to this because I recognize the argument from database work. Nothing has failed. Why are we paying so much to keep it that way?
The answer cannot just be, “Trust us.” But it does not have to be. Y2K left evidence, and some of the most useful evidence came from the things that still went wrong.
Two Digits Made Sense. Until They Didn’t.
The Year 2000 problem, shortened to Y2K, grew out of dates stored with two digits for the year. A program could treat 99 as 1999 but misread 00 as 1900. Other date calculations could fail differently. The missing century was the problem; the result depended on the code.
It is easy to laugh at the saving now. The smallest IBM 1401 was offered with 1,400 characters of memory. A standard IBM punched card had 80 columns. Two characters were worth arguing over.
Alan Greenspan had done it himself. Recalling his programming days, he described being proud of the space he saved by leaving out the 19. His admission appears in the Congressional Record: “I am one of the culprits who created the problem.”
That is more interesting than a story about careless programmers. A useful saving came with an assumption about the century. The code kept running long enough for that assumption to become a problem.
Anyone who has maintained a temporary solution for years will understand.
The Deadline Was Not a Surprise
Bob Bemer published warnings about the problem in 1971 and 1979. This was not a defect discovered in the last week of December.
But knowing about a deadline and being ready for it are different things. In May 1997, only 21 percent of the mission-critical systems at 24 major US federal agencies were reported compliant. By December 1999, that figure was 99.9 percent, according to the government’s subsequent review.
Those are reported readiness figures, not proof that every test was perfect. Still, they describe work completed before midnight. The quiet morning afterward is not the only evidence we have.
Someone Had to Read the Code
The work meant finding affected systems, following their connections, changing date handling, and testing the results. It also meant preparing a way to keep operating if a repair failed.
Think about what that asks of the person doing it. A two-digit field is easy to spot. Understanding every calculation, file exchange, and report that depends on it is another matter.
You cannot fix that by replacing every 99 with 1999. You have to understand what the program means.
And the business still needs the program. Payroll has to run. Payments have to move. You are changing something people depend on while they continue to depend on it.
That is the part of maintenance I wish more people could see. Not just the change, but the care needed to make it without creating the next problem.
The Pieces Passed. The System Failed.
During the rollover, a US intelligence ground-processing system stopped processing satellite data. The satellites themselves remained under control. The failure was on the ground.
At a January 4, 2000, briefing, Deputy Secretary of Defense John Hamre explained the testing problem. The service had to keep operating, so testing had been done in segments. The segments worked. Put together, they did not.
Backup procedures were operating before midnight in Washington. They initially provided less than normal capacity, but covered the high-priority military requirements.
There is the story in miniature. Preparation did not prevent every failure. Preparation also included the people and procedures that contained a failure when it arrived.
Calling that “nothing happened” leaves out the breakdown, the diagnosis, and the recovery. It leaves out almost everything a database professional would want to learn from it.
The Money Went to the Wrong Banks
The Federal Reserve had an equally instructive incident. Governor Edward Kelley described a Y2K error in one district’s system that misallocated millions of dollars to the wrong banks.
The problem was fixed within two hours. The allocations were identified and reversed. Kelley reported that nobody was hurt or inconvenienced.
That last sentence is the successful outcome. The two sentences before it explain how it was achieved.
There were less dramatic date errors too. A federal review recorded Medicare claims arriving with service dates of 1900 or 2099. Most of those errors were traced to providers that had not upgraded their systems.
Some faults survived the preparation. Some systems were not ready. Those are different explanations, and neither is the same as saying the bug was imaginary.
A Real Problem Can Still Be Overfunded
None of this proves that every dollar spent on Y2K was necessary. That would be the same bad argument in reverse.
Countries came through with different levels of preparation and different dependence on computers. Kelley also described organizations replacing old systems altogether. Comparing their final outcomes does not tell us, by itself, which spending was necessary and which was waste.
Two questions deserve separate answers.
Were there real defects? Yes. We have documented failures, repairs, and recoveries.
Did every purchase and project earn its cost? The existence of those defects does not establish that. A project still needs a reason for its scope and its bill.
You can respect the engineers who fixed a real problem and question what was spent around them. You do not have to choose one.
The Evidence Was in the Wrong Place
I used to think prevention was unprovable. That is too easy an answer.
A repair can leave a failing test, the change that fixes it, and a passing result. A recovery can leave a timeline showing what stopped, what was restored, and how long it took.
That will not tell us exactly what an unrepaired world would have looked like. It will tell us considerably more than a photograph of people celebrating at midnight.
The quiet morning was the outcome. It was not the whole record.
Imagine finding a defect in October, fixing it, and proving the fix in November. By January, it is old news to your team. To someone outside the team, it may never have been news at all.
The work has evidence. The person judging the work may never have seen it.
Your Backup Job Has the Same Problem
This is where the history becomes useful on Monday morning.
There is protection you have tested, and there is routine you have inherited. Both can produce a green status on a report.
A successful backup job tells you the job completed. A restore test, with checks on the restored database, gives you evidence about recovery. Record the time it took, too. Being able to recover is not the same as recovering within the time the business can afford.
An untested backup may be perfectly usable. You just have less evidence for the promise you are making. And last quarter’s successful test does not certify every backup you have taken since.
The same question belongs beside a failover plan or an index maintenance job: what have we checked, and what does that check actually establish?
Do not defend a routine merely because it runs quietly. Do not discard it merely because the failure it guards against has not happened. Examine the reason for it, test what you can, and keep the results.
Keep the Evidence Before Someone Asks
What stays with me about Y2K is not the size of the bill. It is how easy it is to look at a working system and miss the people who helped it stay that way.
They deserve more than a claim that disaster was inevitable without them. They deserve an account of what they actually found and fixed.
This question, which work earns our trust and which work merely inherits it, also runs through my book AI: Nobody’s in There. But we’re still in here. You can read the essays at pinaldave.com, or find the paperback on Amazon.
I know what it feels like to maintain something that has not failed, then be asked to justify it by someone who has only seen it working. I would rather answer with the restore result, the defect we caught, and the recovery drill than ask for faith in my job title.
That folder will not justify everything. It will let us have an honest conversation about what it does justify.
If you spot a factual inaccuracy, please let me know. I am happy to correct it.
Keep the evidence while the work is fresh. You should not have to reconstruct it when someone finally asks.
This is not a reason to defend every maintenance job, it is a reason to show which ones earn their keep.
Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.
