A good friend of mine was (and still is) a civil/construction engineer. Other than some introduction courses in college, he had never done any programming before. But after losing his job in 1998, he was hired by a major European consulting company to work on the Y2K problem.

With an auditorium full of others who had barely any programming experience, he was given a crash course in Cobol for a month, and then he had to go through thousands of lines of code of bank software that ran on some mainframe and identify all cases where a date was hard-coded as 2 characters.

Extremely tedious work, but there were tons of fixes to be made.

The problem was real, and the billions that were spent on fixing things were necessary.

I’m wondering what happened to the people in meeting rooms who suggested that this could be automated if it needed no deep understanding of the COBOL language or the banking domain..?

EDIT (for clarity): that’s what I would say, and I’m pretty sure many people smarter than I had said it - so I’m just curious what objections made business push forward with the “relatively unskilled” human labour intensive practices instead, because that’s the history we have now.

There were tools available, but it was increasing the risk (in a risk-averse atmosphere) to trust them to catch all cases. Try explaining to your superiors why you were given the task of fixing the issue and instead of completely fixing it you saved some money. Probably unacceptable.

Also, much of the remediation could not be automated anyway (for example you may not be able to assume the century is '19' for a given date field which can be in the future. You may need to do a comparison to a cutoff date, or you may only have to enlarge the field knowing that the value is supplied from elsewhere which will itself get fixed), so it fell back to people looking at the code, understanding it just enough, making the required changes, and planning/executing the testing.

I'm not a COBOL expert, but I suspect you misunderstand both the difficulty of teaching a machine to understand the problem well enough to automate fixes for it and the available computing resources at the time. This was still the era of Windows 95, the classic Mac, and expensive workstations.

I worked for a place that simulated what would have happened with an older device. It would have been pretty catastrophic... easily losses in the billions.

Remember that big old systems were the low hanging fruit in 1970. The business logic was COBOL and assembler, without things like functions. The system may have hundreds of duplicate routines for things like subtracting dates.

if you're asking "was the money well spent?" then I'm sure it was as well spent as usual, i.e. mistakes got made, a percentage was wasted and some contractors made very good rates. But in the end we got there.

If you asking "would it be better to have done nothing?" then I would have to say No, of course not. What are you thinking?

>..and what would be the cost (when compared to those billions of dollars spent) if they weren't fixed at all.

I worked on fixing Y2K bugs at the time. It was very methodically and planned, and tested on-site at a space agency. If we hadn't fixed those Y2K issues at the time then weather forecasts would have suffered greatly. The cost of that happening? Hard to calculate I think.

Lots of fixes were made. Everything would have broken if they hadn't been fixed.

Why are you sceptical about this?

Lots of people seem to come up with it now. It's been two decades, and it's brought up by people who use it as an example in their other other agendas:

"look at y2k: we spent so much money, and nothing happened!" (so far, so good) "...therefore, if we hadn't, nothing would have happened anyway!!" (uh, based on...?) "...and it was all a massive scam, just like any massive present issue!!!" (ah, there's the underlying reason)