3 ms·

> Finally, it was a fake job because the problem that the Conglomerate had hired Andersen to solve was not real, I don't really like the whole popular understa

by mlyle 2y ago

> Finally, it was a fake job because the problem that the Conglomerate had hired Andersen to solve was not real, I don't really like the whole popular understanding of the y2k thing. Substantial problems with infrastructure were fixed. It wouldn't have been Mad Max, but business operations could have been affected for weeks. Instead, we had almost smooth sailing because there was an appropriate amount of preparation beforehand. (Not to say that there wasn't graft like he describes as part of that preparation).

magicalhippo 2y ago
Back when I was just out of school, I worked as a computer tech guy. Our company got hired to test all the PC+BIOS version combinations a certain department had, to ensure they'd work after y2k. Spent several weekends rigging up computers, and running a battery of tests on them. Did actually find a handful of combos which misbehaved, mostly incorrectly handling the leap year IIRC. None of them had NTP running, so could have been an issue. A few didn't handle the transition well at all. Most got resolved by a BIOS update. I recall thinking after 2000 came and went that sure, a fair share of superfluous work had probably been done, but the reason it seemed like such a nothingburger afterwards was because a lot of work went into ensuring exactly that.
dgfitz 2y ago
I read it as, a real problem wasn’t identified by the management side of the company. Finding typos in spreadsheets and printing corrected versions to slap in a binder was a CYA event, the article says as much.
RHSeeger 2y ago
> The problem was known variously as Y2K, ... I really hate this take some people have (especially people that weren't there at the time) that Y2K wasn't a real problem. It was a real, large problem effecting businesses across the globe. But the thing is, the problem wasn't that "everything was going to fail catastrophically at the turn of the year". It was that "some things could fail catastrophically at the turn of the year, and we didn't know which things would". So a lot of time and money went into figuring out which things actually had a problem, and fixing them. It was entirely possible that, if we didn't fix something, planes _could_ fall out of the air, or energy providers could shut down for long periods of time. So we spent lots of time and money finding out what things needed to be fixed. And "it turns out that not that not that many things did really need to be fixed" is a GREAT result from that time and money; arguably the best possible result. But it doesn't invalidate that the time and money was spent, in the same way that "I didn't get into an accident" doesn't invalidate the fact that wearing your seat belt is a good idea.
cromulent 2y ago
It's infuriating. I worked on a Y2K project in 98-99 for a major car manufacturer. They tested the ERP system for Y2K (in 1997) and it failed, in a way that would make the business fail. They replaced it via this project and the business continued to be successful without interruption. Another company I know of simply backdated their whole system by 10 years. This worked, but unfortunately the contract cycle renegotation reminders then did not appear, and competitors took many of their contracts over the next year or so. They went out of business in a couple of years. I implemented a new manufacturing and retail system in 1992, and we used 4 digit years. The company owner complained that they were a needless expense and annoyance and that there was plenty of time to deal with Y2K. They continued to use the system well into the 2000s. The space shuttle never flew over New Year's eve/day as they couldn't handle a single year rollover, let alone a century. Some use cases can simply avoid the problem.
- kens 2y ago
  Strangely enough, a few months ago I came across the bug fix for that Space Shuttle problem. "CR 93160: Year End Roll Over (YERO) Reset. Allows in-flight reset to January 1 without an IPL and complicated procedures while maintaining a good state vector." (IPL is "Initial Program Load", IBM-speak for a reboot.)
- RaftPeople 2y ago
  > It's infuriating. I worked on a Y2K project in 98-99 for a major car manufacturer. They tested the ERP system for Y2K (in 1997) and it failed, in a way that would make the business fail. They replaced it via this project and the business continued to be successful without interruption. Same. I worked on multiple enterprise projects for Y2K where we advanced the dates on the customer's system and ran it so we could see the magnitude of the problems and prioritize the remediation process. There were some things that were temporarily annoying and there were some things that were critical to the business and could not be worked around manually by throwing people at it, the system needed to be fixed.
zugi 2y ago
Perhaps this line from further down is what was meant by "not real": > The Andersen position was that “Y2K is a documentation problem, not a technology problem.” Sure, there were other people at other companies solving the "real" Y2K problem, but the problem Andersen was solving was not so real.
iwishiknewlisp 2y ago
*she
shever73 2y ago
The whole article was full of supercilious snark. A lot of it was aimed, rightly, at Andersen, but it does take away from the fact that Y2K was a real issue that affected millions of computers worldwide. I patched hundreds of vulnerable systems, rewrote code for mission-critical software and still ended up with a call-out to halted manufacturing plant on January 1st, 2000. If there hadn’t been a global, coordinated response, things would have been a lot worse. And let’s not forget that there were life-changing effects of the bug beyond the snarky “garage door opener” issue mentioned in the article. [0] [0] https://www.theguardian.com/uk/2001/sep/14/martinwainwright https://www.theguardian.com/uk/2001/sep/14/martinwainwright

by mlyle 2y ago

magicalhippo 2y ago

Back when I was just out of school, I worked as a computer tech guy. Our company got hired to test all the PC+BIOS version combinations a certain department had, to ensure they'd work after y2k. Spent several weekends rigging up computers, and running a battery of tests on them. Did actually find a handful of combos which misbehaved, mostly incorrectly handling the leap year IIRC. None of them had NTP running, so could have been an issue. A few didn't handle the transition well at all. Most got resolved by a BIOS update. I recall thinking after 2000 came and went that sure, a fair share of superfluous work had probably been done, but the reason it seemed like such a nothingburger afterwards was because a lot of work went into ensuring exactly that.

dgfitz 2y ago

I read it as, a real problem wasn’t identified by the management side of the company. Finding typos in spreadsheets and printing corrected versions to slap in a binder was a CYA event, the article says as much.

RHSeeger 2y ago

> The problem was known variously as Y2K, ... I really hate this take some people have (especially people that weren't there at the time) that Y2K wasn't a real problem. It was a real, large problem effecting businesses across the globe. But the thing is, the problem wasn't that "everything was going to fail catastrophically at the turn of the year". It was that "some things could fail catastrophically at the turn of the year, and we didn't know which things would". So a lot of time and money went into figuring out which things actually had a problem, and fixing them. It was entirely possible that, if we didn't fix something, planes _could_ fall out of the air, or energy providers could shut down for long periods of time. So we spent lots of time and money finding out what things needed to be fixed. And "it turns out that not that not that many things did really need to be fixed" is a GREAT result from that time and money; arguably the best possible result. But it doesn't invalidate that the time and money was spent, in the same way that "I didn't get into an accident" doesn't invalidate the fact that wearing your seat belt is a good idea.

cromulent 2y ago

It's infuriating. I worked on a Y2K project in 98-99 for a major car manufacturer. They tested the ERP system for Y2K (in 1997) and it failed, in a way that would make the business fail. They replaced it via this project and the business continued to be successful without interruption. Another company I know of simply backdated their whole system by 10 years. This worked, but unfortunately the contract cycle renegotation reminders then did not appear, and competitors took many of their contracts over the next year or so. They went out of business in a couple of years. I implemented a new manufacturing and retail system in 1992, and we used 4 digit years. The company owner complained that they were a needless expense and annoyance and that there was plenty of time to deal with Y2K. They continued to use the system well into the 2000s. The space shuttle never flew over New Year's eve/day as they couldn't handle a single year rollover, let alone a century. Some use cases can simply avoid the problem.

kens 2y ago
Strangely enough, a few months ago I came across the bug fix for that Space Shuttle problem. "CR 93160: Year End Roll Over (YERO) Reset. Allows in-flight reset to January 1 without an IPL and complicated procedures while maintaining a good state vector." (IPL is "Initial Program Load", IBM-speak for a reboot.)
RaftPeople 2y ago
> It's infuriating. I worked on a Y2K project in 98-99 for a major car manufacturer. They tested the ERP system for Y2K (in 1997) and it failed, in a way that would make the business fail. They replaced it via this project and the business continued to be successful without interruption. Same. I worked on multiple enterprise projects for Y2K where we advanced the dates on the customer's system and ran it so we could see the magnitude of the problems and prioritize the remediation process. There were some things that were temporarily annoying and there were some things that were critical to the business and could not be worked around manually by throwing people at it, the system needed to be fixed.

zugi 2y ago

Perhaps this line from further down is what was meant by "not real": > The Andersen position was that “Y2K is a documentation problem, not a technology problem.” Sure, there were other people at other companies solving the "real" Y2K problem, but the problem Andersen was solving was not so real.

iwishiknewlisp 2y ago

*she

shever73 2y ago

The whole article was full of supercilious snark. A lot of it was aimed, rightly, at Andersen, but it does take away from the fact that Y2K was a real issue that affected millions of computers worldwide. I patched hundreds of vulnerable systems, rewrote code for mission-critical software and still ended up with a call-out to halted manufacturing plant on January 1st, 2000. If there hadn’t been a global, coordinated response, things would have been a lot worse. And let’s not forget that there were life-changing effects of the bug beyond the snarky “garage door opener” issue mentioned in the article. [0] [0] https://www.theguardian.com/uk/2001/sep/14/martinwainwright https://www.theguardian.com/uk/2001/sep/14/martinwainwright