'My Fake Job In Y2K Preparedness' (nplusonemag.com) 114
Long-time Slashdot reader theodp writes:
The Contingency Contingent, is Leigh Claire La Berge's amazing tale of what she calls her "fake job in Y2K preparedness." La Berge offers an insider's view of the madness that ensued when Y2K panic gave rise to seemingly-limitless spending at mega-corporations for massive enterprise-wide Y2K remediation projects led by management consulting firms that left clients with little to show for their money. (La Berge was an analyst for consulting firm Arthur Andersen, where "the Andersen position was that 'Y2K is a documentation problem, not a technology problem'.... At a certain point all that had happened yesterday was our documenting, so then we documented that. Then, exponentially, we had to document ourselves documenting our own documentation."). In what reads like the story treatment for an Office Space sequel, La Berge writes that it was a fake job "because Andersen was faking it."
From the article: The firm spent the late 1990s certifying fraudulent financial statements from Enron, the Texas-based energy company that made financial derivatives a household phrase, until that company went bankrupt in a cloud of scandal and suicide and Andersen was convicted of obstruction of justice, surrendered its accounting licenses, and shuttered. But that was later.
Finally, it was a fake job because the problem that the Conglomerate had hired Andersen to solve was not real, at least not in the sense that it needed to be solved or that Andersen could solve it. The problem was known variously as Y2K, or the Year 2000, or the Y2K Bug, and it prophesied that on January 1, 2000, computers the world over would be unable to process the thousandth-digit change from 19 to 20 as 1999 rolled into 2000 and would crash, taking with them whatever technology they were operating, from email to television to air-traffic control to, really, the entire technological infrastructure of global modernity. Hospitals might have emergency power generators to stave off the worst effects (unless the generators, too, succumbed to the Y2K Bug), but not advertising firms.
With a world-ending scenario on the horizon, employment standards were being relaxed. The end of the millennium had produced a tight labor market in knowledge workers, and new kinds of companies, called dot-coms, were angling to dominate the emergent world of e-commerce. Flush with cash, these companies were hoovering up any possessors of knowledge they could find. Friends from my gradeless college whose only experience in business had been parking-lot drug deals were talking stock options.
Looking back, the author remembers being "surprised by how quickly Y2K disappeared from office discourse as though censored..."
Their upcoming book is called Fake Work: How I Began to Suspect Capitalism is a Joke.
From the article: The firm spent the late 1990s certifying fraudulent financial statements from Enron, the Texas-based energy company that made financial derivatives a household phrase, until that company went bankrupt in a cloud of scandal and suicide and Andersen was convicted of obstruction of justice, surrendered its accounting licenses, and shuttered. But that was later.
Finally, it was a fake job because the problem that the Conglomerate had hired Andersen to solve was not real, at least not in the sense that it needed to be solved or that Andersen could solve it. The problem was known variously as Y2K, or the Year 2000, or the Y2K Bug, and it prophesied that on January 1, 2000, computers the world over would be unable to process the thousandth-digit change from 19 to 20 as 1999 rolled into 2000 and would crash, taking with them whatever technology they were operating, from email to television to air-traffic control to, really, the entire technological infrastructure of global modernity. Hospitals might have emergency power generators to stave off the worst effects (unless the generators, too, succumbed to the Y2K Bug), but not advertising firms.
With a world-ending scenario on the horizon, employment standards were being relaxed. The end of the millennium had produced a tight labor market in knowledge workers, and new kinds of companies, called dot-coms, were angling to dominate the emergent world of e-commerce. Flush with cash, these companies were hoovering up any possessors of knowledge they could find. Friends from my gradeless college whose only experience in business had been parking-lot drug deals were talking stock options.
Looking back, the author remembers being "surprised by how quickly Y2K disappeared from office discourse as though censored..."
Their upcoming book is called Fake Work: How I Began to Suspect Capitalism is a Joke.
Over-hyped, not fake (Score:5, Insightful)
A lot of systems could have failed in ways people depending on them would have found catastrophic. I was never concerned about my vehicle's BCM shutting down on New Years, but a lot of accounting and control systems were coded with 2-digit dates baked in and endless code written expecting to be passed 2-digit dates.
Code audits and seamless patch deployments for everything (keeping in mind that for a lot of items you don't even know until the audit whether you need to worry about patching) was a huge job.
The Y2K panic resulted in there being nothing to worry about, because the issue was given more attention than it really required and everything of importance was patched well in advance.
Now that it's a quarter century in the rearview mirror, I'd kind of like to see a technical breakdown of what actually would have broken down if we hadn't done anything, and compare how much we spent on Y2K prep vs. estimated disaster recovery if we had done nothing. I suspect we spent WAY too much, but it wasn't all waste, there was some real need.
Re:Over-hyped, not fake (Score:5, Insightful)
The Y2K panic resulted in there being nothing to worry about, because the issue was given more attention than it really required and everything of importance was patched well in advance.
It seems a lot of people called Y2K a scam now because all the work mitigated the effects of the problem. One area that was very sensitive to it was banking. My computer not working was not as big a deal as my bank's mainframe not working. Compounding the problem is that banking used and still uses COBOL which means programmers are scarce. Part of Y2K effort was not so much fixing code but auditing it to make sure that it would not fail when the year rolled over. Fixing it was secondary. For legacy systems like COBOL, that was a challenge coaxing any living programmers out of retirement.
Re: (Score:3)
No that's a binary view of thing there where parts of it that where real and needed to be addressed, but there was also a lot of fear spreading. I remember watching the News and seeing a lady saying we need to worry about your hair drier or your microwave not working because of Y2K. Not one presenter questioned her on it, because she was the "expert". Sure the clock on your microwave maybe wrong but as long as you didn't use it at midnight everything would have been fine otherwise.
Re: Over-hyped, not fake (Score:3, Interesting)
Indeed. The world spent $300-$600B (in 2000 dollars) and the damage done by the problem was a minuscule fraction of that. Nobody would say "nothing should have been done", but that ratio makes clear that far too much was spent on prevention rather than remediation.
Furthermore, we have clear evidence it was pointless. One study showed that a quarter of Y2K bugs should have happened *before* the year 2000, with the start of 1999 (when most remediation projects were far fro.m complete) being especially common
Re: Over-hyped, not fake (Score:5, Insightful)
The reason so little damage was done was... the effort to ensure there was little damage done.
It makes no sense to compare the effort with the resulting damage. None what so ever. If there is a flood, and I have spent a lot of money ensuring my house will survive the flood, was that then a waste because my house ended up taking very little damage?
Re: (Score:2)
Sometimes issues can be perfectly and completely resolved, despite being real issues. eg: If you don't pay your bill by this date, your electric will be shut off.
Re: Over-hyped, not fake (Score:4, Insightful)
There were lots of systems fixed that didn't really need to be fixed, but there were many where the fix was crucial. The problem is that once the hype started, nobody made that distinction. Windows 95A started sorting files incorrectly by date, but that, to me, was only an annoyance that didn't really need to be fixed. (It wasn't even the worst annoyance.) But the system I wrote for calculating people's ages and whether they qualified for benefits needed to be patched. (I cheated, and put in a rule that anyone under 8 years old qualified for a reduced rate transit pass if they came in and got their id card. That was "good enoud", as the system didn't last another 8 years, and since it ran on a mainframe fixing it properly would have been quite expensive. Before the 8 years was up we'd moved the system to a microcomputer.)
Handling it properly would require those making the decisions to understand the systems they were making the decisions for, and many managers didn't like delegating that kind of authority.
Re: (Score:3)
I worked on Y2K at a large company that was a conglomerate of different well known brand names
When I got on the job most things had been ground down to lists of systems that needed components replaced, or various patches provided. I helped run those down, and closed out the last two that cropped up towards the end; 1. A system written in the 70's that was still running, and 2 A new system that was just being rolled out at the close of our project.
1. The system that was written in the 70's, had a three ring
Re: (Score:2)
Y2K problems where a problem for Big Iron line payroll systems, tax stuff, insurances and banks.
Mentioning schools shows that you actually have no clue about the topic.
If your pay check is not paid out because the systems assumes you retired 100 years ago, then you seriously can wait a while until the programmers find the place where the bug is.
XX00 < YY99 --- does not hold for various types of variations of XX and YY. So your program logic goes into the opposite branch when XX is 20 and YY is 19.
Re: Over-hyped, not fake (Score:3)
I can assure you that you don't understand how fucked the supply chain for basic needs would have been without mitigations being applied.
But everybody thinks it would have been easy to load trucks by hand based on hand written paperwork and loading instructions.
Hospitals and basic food staples would have been fucked; but hey, it's nothing.
Re: (Score:2)
Furthermore, we have clear evidence it was pointless.
Citation needed.
Re: Over-hyped, not fake (Score:2)
You can find links to all these things on the Y2K wikipedia page.
Let's not forget Enron's connections (Score:2)
Wendy Gramm, wife of US senator Paul Gramm, was on Enron's board. Connection from corporate board to the US Senate.
Re: (Score:1)
Re:Over-hyped, not fake (Score:5, Insightful)
The "problem" is that it's like any other disaster preparation exercise. Most of the spending probably wasn't needed--the applications would have been fine or the consequences manageable if nobody audited or fixed it. But you don't know what you don't know so you spend money protecting yourself against any and every Y2K-related risk you can imagine. Those of us who were in the trenches KNOW there was an actual problem that we largely avoided. The monday morning quarterbacks who look back and say we scammed everybody because we spent more than was strictly necessary to "fix" things that didn't end up breaking (kind of the point...?) are just noise.
OTOH, the Y2K consulting industry could smell the money, so I'm not going to argue that every dollar in "Y2K prep" was spent wisely. Not by a long shot. But I'm pretty sure that's not a Y2K problem--it's a consulting industry problem. I think in some ways big consulting firms are extremely subtle and sophisticated scammers overcharging for what they can't possibly deliver.
Re: (Score:2)
Re: (Score:2)
What is the ethical cut-off date for ignoring this stuff?
Some of the embedded systems I built will wrap back to 2000/01/01 in 2068. I really doubt they will still be in use at that point, but when I was working on fire safety stuff I made a point of extending it to at least 2100, with full testing, because the buildings may potentially not be renovated 80+ years later.
Re: (Score:2)
I don't think most corporate software does such important work as "cancelling insurance contracts" or "eliminating pensions". And most of the software I've worked on has been designed--eventually--to fail safely. It's not "Oh noes! I crashed so I'm going to cancel everyone's life insurance!" It's more like "I crashed so I'm going to let people know and if the programmers take too long to fix it processing will be done manually."
The real problem would have
Re: (Score:1)
NB - gp poster has been known to post earnestly on the secret religious meaning of number relationships and how they can be used to help you succeed at gambling.
You're not wrong that they're hungry but you're also interpreting their screed as something much more coherent than it actually is.
Re: (Score:2)
Re: (Score:1)
Perhaps you should learn to read.
Y2K problems do not make software crash.
They make the old if/else/while constructs take the wrong path.
Seriously? Troll?
You are a fucking idiot.
Re:Over-hyped, not fake (Score:4, Interesting)
There was no panic.
At least not in Europe.
And the idea: the computers would crash is utter nonsense.
if (today < contractEndDate ) {
sentInvoice();
} else {
cancelContract();
sentThankYouLetter()>
}
It is obvious what happens if you have code like this:
if (XX00 < YY99) {
}
Obviously 2000 is not smaller than 1999.
So? You grasp it or not? This is a Y2K bug. That needs to be fixed, or your program does nonsense. But in general it does not crash. It just takes wrong logic paths.
E,g. You have on top of that wrong calculations of leap years. And that means a one day offset in "what day of the weak is today? Monday or Sunday?"
There where bugs deep into 2010, 2020, when people activated a software feature in a config file, which would automatically unlock shopping mall doors on a Monday morning, but it was Sunday and the mall was supposed to be closed. So for years some staff had to manually lock the doors again. And the developers where pulling their hairs and did not grasp: it is a Y2K related problem. Yeah, or weekdays where the elevators did not work. To save on maintenance, the software halted the elevatored where ever it was, opened the doors: and disabled all controls.
There are thousands of freak bugs which you need to experience to grasp them.
Disclaimer: I did Y2K reengineering, and refactored about a million line of COBOL code and a few 100k lines of PL1.
However we did not do the bullshit our competitors did. We used a smart compiler that did data flow analyzis. It tagged basically every byte/word in the code that once in a time hold a date.
Re: (Score:1)
Re: (Score:2)
Much of the financial sector is still in COBOL, which is, yes, BCD.
Re: (Score:1)
Yes, BCD or even ASCII.
Actually ASCII, as a BCD would fit two digits into a single byte.
Re: (Score:2)
Or EBCDIC. . . .
Re: (Score:1)
That is more a text format, alternative to ASCII.
Do not know much about EBCDIC.
The interesting question is (that was never relevant for my work), if "numbers" in COBOL are indeed BCD.
Would make sense. But would completely contradict the idea that "we used 2 digits to save space" as 4 digits would be only 4 nibbles aka 2 bytes.
Re: (Score:2)
FWIW, the database I used preferred to store the numbers as text. And memory was TIGHT. So, yes, I used 2 digit years. And to avoid the y2k problem I did the arithmetic mod 100 and calculated the delta between that year and the current year. Someone young enough could have posed as qualified for an elderly transit discount card, but I think that when they came in to get their photo id it would have been detected.
Re: (Score:2)
This is where it broke down on medical systems. Because the same system would would have a larger than 100 year difference between their youngest and oldest patients.
Re: (Score:1)
Using the delta between that calculation is called "Windowing"
You span a window of 100 years, e.g. from 1945 to 2044, if a number is smaller than 45, it is prefixed with 20. If a number is greater or equal to 45, it is prefixed with 19. Some use "sliding windows" aka, the 45 above gets updated each year.
That means, you only need to fix the if's/while's etc. where two numbers are compared. And have no API changes or external storage changes.
The other popular method, but expensive, was called "Expansion", you
Re: (Score:2)
It wasn't a good fix, but it was "good enough'. Actually the people using they system had a potential range of over 100 years, but the number of exceptions was small enough that I don't think I ever encountered one. Very few centenarians use transit, and very few under 8 who are qualified for a disability pass. So basically the system would potentially get confused if someone was under 4 or over 104, but I don't think it ever happened.
Re: (Score:2)
Not really, and that was the problem. LOTS of databases used ascii numbers for numbers. "98" for 1998, for example. It saved space, and the database set up in 1980 it seemed ok, because *someone* would fix it in the next 20 years, or that was the hope. Programs rarely do arithmetic on dates, even though these can be numbers, so entry level SQL poeple used strings a lot, and were sometimes taught to do that
A lot of financial stuff did not use basic binary, they used Binary Coded Decimal for the arithmetic
Re: (Score:1)
That has nothing to do with fixing.
And has nothing to do with saving space.
Get a damn bill, or letter or what ever from the year 1980.
Does not matter if hand written or printed out by an IT system.
The dates are all two digit years. Until roughly 1999, I never wrote a date by hand with 4 digits, no one did. No one did in real life write a date with 4 digits . Hence: we did it neither in computer software.
Until roughly 1993, no one was even thinking about a Y2K problem.
We did not use 2 digits to save space. T
Re: (Score:1)
Addition: 1900 was not a leap year. 2000 was.
Re: (Score:1)
Virtually all of that work was done before any layman even knew about a Y2K issue. By the time it was known to the public, it was all grift.
"...what actually would have broken down if we hadn't done anything"
Who's "we" here? Are you taking credit? The "we"'s of Y2K were all grifters, the people solving problems had done their work already.
"I suspect we spent WAY too much, but it wasn't all waste, there was some real need."
Quite an analysis from the peanut gallery. If "we" had spent NOTHING on "Y2K" it's
Re: (Score:2)
At the time, no one had to explain what Y2K was. But I was still working on it.
Y2 is still going on today... (Score:3)
Nice FP, and I pretty much concur with your comments, but don't have much worth adding add there.
However I just recently ran into the bug as I was using ChatGPT to create a new front end to a database designed back in those days. I actually tagged the windowed year field "Y2" as a 2-digit kludge pending resolution. However ChatGPT lost its marbles (again) before I got to the stage where I had to resolve the problem one way or another... (Now pondering the options for progress. Some of them seem to be (1) Tr
Re: (Score:3)
I think it weighs in between the "nothing would have happened" versus the "complete obliteration of society". Just the amount of cash thrown at it could fix almost anything. Things like A/C thermostats, CNC equipment, and other items were more of a concern. I do wonder what items that would have caused major problems, as in grid down scenarios, were stuff that was worth throwing the tsunami worth of money at.
It is ironic how things changed. If there were another Y2K-like event coming up (like the UNIX e
Re: (Score:3)
Re: (Score:2)
Probably a lot more than you think. Banks knew about the problem since the mid-70s, because when you're dealing with a 25 year mortgage, anything after 1975 wil
Re: Over-hyped, not fake (Score:2)
Oh the good old days of tech (Score:4, Informative)
1999, you could scribble the word computer on your resume in crayon, or submit a medical report showing you were alive, and you'd have a tech job. Funniest were the resumes with 10 years of Java experience. They'd still get hired of course.
Re: (Score:2)
Them were some funny times. I was working at a uni at the time and we had a class of "honors" CS students, some of whom were in my lab. I gave them small job to see what they could do, more or less a "Hello World" in Java that also computed some silly numbers. You'd have thought I had asked for theory of the universe and two examples. I gave up. Shortly thereafter they were hired out in Colorado under the Y2K euphoria. I cannot imagine them being employed today or who would be stupid enough to hire them.
Re: (Score:2)
Capitalism isn't the same as greed.... (Score:4, Insightful)
Re: (Score:1)
"Anyone with a computer science degree knows epoch rollover is a real issue for historical data with no temporal anchor."
Bullshit. Anyone with a computer science degree knows that computers handle dates in different ways, almost none of which were vulnerable to Y2K. And what's a "temporal anchor"? Y2K originated in old databases that assumed the 20th century, the problem was literally A "temporal anchor".
"This article and arguably this book are both equally ignorant."
Or you are. I think we know the answ
Re:Capitalism isn't the same as greed.... (Score:4, Informative)
Temporal anchor: Unix time is counted in seconds from midnight 1st January 1970.
Temporal anchor: the year 2024, is counted to be 2024 years after the birth of a guy called Jesus. Give or take 3 or 4 years.
Temporal anchor: The year Buddha achieved enlightenment is the year 0, now we are in the year 2567 (in Thailand, other countries like Tibet, picked a different anchor)
And so on.
Hopes that helped ...
Anyone with a computer science degree knows that computers handle dates in different ways, almost none of which were vulnerable to Y2K.
About 4% of all code lines in a business application handle or deal with dates.
Half of them are vulnerable to Y2K problems, because they are if's/while's and so on.
The problem is to find those 2% of lines.
You know nothing about the topic.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:1)
Falsehoods about time: https://www.wired.com/2012/06/... [wired.com]
You find some similar (and much bigger) lists on github.
Re: (Score:2)
Absolutely not fake (Score:4, Informative)
I worked at a place that processed claims for the biggest insurance carriers, there were serious Y2K bugs that were fixed in the late 90s. Not world ending bad but messing up people's finances is a serious matter after all.
Though sometimes the Y2K patches had issues, but another point is that the bug was there and needed to be fixed: https://www.cnet.com/deals/bes... [cnet.com]
Re: (Score:2)
Y2K was not fake as a problem. But a lot of the consulting sold for it, especially from the Big Five, was fake.
Re: (Score:1)
as long as they went through the client's code, how would it be "fake"? Gotta check after all. In the two digit for a year case, fix is easy but all over the place... as long as they did the job it wasn't 'fake'
Re: (Score:2)
Did you read the story?
Re: (Score:1)
Yes I did, you seem to be missing the big picture. Both Enron and AA were proved to be fraudster companies for many other reasons too and they're gone.
I'm talking about the rest of the world.
Re: (Score:2)
You think the remaining "Big Four" are any better? What do you base that on? Wirecard, for example, just showed nicely that EY is not any better than AA.
Re: (Score:3)
I don't think the article means the whole thing was fake, but Anderson were hired to solve a problem an advertising company didn't know the first thing about, and Anderson had no idea what they were doing and were unable to solve the problem.
Yep there were lots of Y2K bugs of varying degrees of severity. This wasn't it. Read the article. Great insight into the absolute shittiness of the big consulting firms, and the crazyness of the 90s computer industry.
Re: (Score:1)
Anderson went out of business in Europe. Fragments got bought up.
There were fraud cases. And suddenly: the name vanished from the landscape.
No idea what exactly happened. But a company I worked for, canceled all the contracts over night.
Everything that was done by Anderson went to IBM and SUN.
Re: (Score:2)
Enron happened. Anderson had been auditing their accounts. Not very well it turns out.
I remember it well, we made a killing (Score:5, Interesting)
selling simplistic software to companies that simply wanted to be Y2K-certified.
Back then I worked for a certain well-known MS-DOS clone vendor. Between 1998 and 2000 - and even slightly after that, go figure... - we sold a Y2K-test-and-fix diskette for DOS machines for £60 that did something really, REALLY trivial: it set the date to Jan 1, 2000, checked if the system reported 1900 and if it did, it installed a small TSR to add 100 years to what the DOS call returned. But most importantly, it popped a huge green popup that said "You are safe!" or "You are now Y2K immune!".
It was a fucking ripoff and most companies that bought it from us knew it full well, if they didn't already know that their machines were okay because they tested them themselves. But they needed an "official" fix to be compliant, and for insurance purposes.
Y2K was not fake, we just fixed it. (Score:5, Informative)
Perhaps it was fake at his crappy-ass fraudulent consulting company, but it was a real problem. I fixed at least 6 different products that would have blown up, but did not because I fixed them. This included products that kept shipping of critical (and non-critical) goods going. You would have had a lot of dead in the water (or at least not coordinated) big rigs as their shipping fleet location, communication, and tracking systems broke.
And that was the thing about Y2K - we figured out there was a problem, we all agreed there was a problem, and we put in the money and effort (a lot of 1999) to fix the problem before it exploded. And we mostly succeeded. Which, I know, is completely incomprehensible now - you'd have a legion of Y2K deniers declaring it could never happen, it'd get completely politicized with certain political parties passing laws forbidding anyone from 'wasting taxpayer money' working on fixing the 'fake Y2K problem' before it turned into a complete clusterf@#$. And of course there's no longer any money or will to fix anything before it completely craters and costs 100x to fix it.
I was there. It was real. We fixed it before it happened. It was a different time.
Re: (Score:2)
Perhaps it was fake at his crappy-ass fraudulent consulting company, but it was a real problem. I fixed at least 6 different products that would have blown up, but did not because I fixed them. This included products that kept shipping of critical (and non-critical) goods going. You would have had a lot of dead in the water (or at least not coordinated) big rigs as their shipping fleet location, communication, and tracking systems broke.
And that was the thing about Y2K - we figured out there was a problem, we all agreed there was a problem, and we put in the money and effort (a lot of 1999) to fix the problem before it exploded. And we mostly succeeded.
Agreed, any software dev should realize that an untested edge case in a core data type across many interconnected systems has a huge protection to go haywire.
I don't know what Andersen in specific was doing, but giving the software management practises of the time actually documenting which systems had been tested and which had been fixed was probably an important service.
Which, I know, is completely incomprehensible now - you'd have a legion of Y2K deniers declaring it could never happen, it'd get completely politicized with certain political parties passing laws forbidding anyone from 'wasting taxpayer money' working on fixing the 'fake Y2K problem' before it turned into a complete clusterf@#$. And of course there's no longer any money or will to fix anything before it completely craters and costs 100x to fix it.
I was there. It was real. We fixed it before it happened. It was a different time.
Well to be fair, if someone was spending a lot of money prepping systems for Y2K in 2024 I'd be pretty skeptical too...
Re: (Score:3)
Re: (Score:2)
Which, I know, is completely incomprehensible now - you'd have a legion of Y2K deniers declaring it could never happen, it'd get completely politicized with certain political parties passing laws forbidding anyone from 'wasting taxpayer money' working on fixing the 'fake Y2K problem' before it turned into a complete clusterf@#$.
And before anybody gets too politically smug, the other party would have randomly just had everyone in unison stop working on Y2K, in say July 1999, because something something mumble mumble.
(Just like they've just mysteriously dropped the mask mandates and vaccination mandates and distancing mandates, as though something had changed.)
My Experience (Score:4, Informative)
Re:My Experience (Score:4, Informative)
Yep. If you get really lucky with internal audit, they may actually know more about some things than you do and might even be helpful. But external audit? Forget it. These people are routinely faking it, especially the remaining Big Four. (Caveat: One of my Jobs is internal IT and IT security audit as a service. Do not expect too much from most people in this profession either.)
Re: (Score:2)
Well, fraudulent "consulting"... (Score:3)
... from a fraudulent company. Obviously, y2k was a pure tech problem. It was also generally overstated, but for some it might have been crippling or lethal. To find that, you would have to dive into the tech, obviously.
Looks like Anderson got what they deserved, even if they were found out on a different mandate. Now please do that to the remaining Big Four, because they are really not any better. Having seen EY and KPMG people bumbling through IT and IT security audits was a real eye-opener.
Re: (Score:1)
The company were we fixed the Y2K problems for: would have been more or less instantly bankrupt if the bugs had hit.
There was nothing overrated or hyped with Y2K bugs.
A bug is a bug.
if (A < B) {
sentPayCheck();
} else {
sentRetirementPapers();
sentThankYouLetter();
removeFromActiveService();
}
Without bug it goes the correct way. And with a Y2K bug the other way.
You certainly do not want to retire your whole current workforc
Re:Well, fraudulent "consulting"... (Score:5, Insightful)
The version control software used by the company I worked for at the time (not written in COBOL) not only failed but corrupted its database if a check-in was made after Y2K. There were definitely things that failed. There were a lot more things that would have failed, but that they were fixed. There was a lot of silliness, e.g. about car computers most of which back then didn't even know the current date. But there was a lot of real stuff.
And guess what. The 32-bit signed apocalypse is not too far in the future, and if you think everything has moved on from that, you are sadly mistaken. There will be a lot of last-minute scrambling to fix things that still store (even ephemerally) dates in terms of seconds since 1-1-1970.
Re: Well, fraudulent "consulting"... (Score:2)
Yes, and no. Well, there were many many problems that had to be discovered, analyzed and fixed, and I did a lot of OT and made a lot of well earned money solving said problems, as did hundreds of thousands of other people.
Salesman, consulting firms, and journalists also made a lot of money, overhyping the issue and spreading the FUD that you're talking about.
Bean counters, and people who think like them don't like things like disaster recovery tests, amelioration of known issues, or other actions not involv
A more modern version (Score:3)
Grifters (Score:2)
"Their upcoming book..."
Grifters gonna grift about their grift.
Reporting in the aftermath, and beyond (Score:5, Interesting)
Here are two articls I randomly found on the subject. The first is from Scientific America [scientificamerican.com] which asked its readers to report their experiences and observations on Y2K. This was published on January 17, 2000. As one reader wrote:
I suspect that the scope of Y2K problems is being quietly under-reported.
As an example, I'm a senior software engineer at one of the largest institutional money management firms on the globe. We spent 20 months of grueling effort and millions of dollars to insure that our applications and interconnections with the rest of the global financial community were Y2K compliant. The size of the task was truly huge; the number of lines of code in our in-house applications alone is in the tens of millions.
I can report that--starting several days before January 1st--our applications started experiencing minor failures due to Y2K issues. These have continued, sporadically, to this moment. We are also aware that other entities (banks, investment firms, etc.) in the financial community are having similar 'glitches,' some serious. None of these problems appear to be show stoppers so far... but I can tell you that the public picture of a non-event doesn't correspond to the reality on my monitors. I can also tell you that the chances of any of this being reported publicly approach zero.
Why?
1. Who wants to appear on any lawyer's radar screen as they wait to unleash a barrage of Y2K-related litigation?
2. Who is eager to publicly admit that, even after all the time and money spent, we STILL missed some Y2K-related bugs?
Better to give the public the story that the problems didn't occur because of massive mitigation efforts, directed by enlightened management.
Name Withheld San Francisco, Calif.
The second article is from Time [time.com], twenty years after Y2K. Their words echo what most on here have said: untold people around the world worked in the background to fix the problem before it happened. As a result, only small, isolated incidents occurred. Then President Clinton's Y2K czar, John Koskinen, deliberately flew on a flight which would be in the air when the new year arrived to show how safe things would be. As he put it:
“Industries and companies don’t spend $100 billion dollars or devote these personnel resources to a problem they think is not serious,” Koskinen says, looking back two decades later. “[T]he people who knew best were the ones who were working the hardest and spending the most.”
. . .
Koskinen and others in the know felt a high degree of confidence 20 years ago, but only because they were aware of the steps that had been taken — an awareness that, decades later, can still lend a bit more gravity to the idea of Y2K. “If nobody had done anything,” he says, “I wouldn’t have taken the flight.”
This woman may have had a fake job, but thousands of others didn't. And the results show.
Management Panic! But it got caught early (Score:3)
Where I worked in the late 1990's we discovered a "Y2K" problem about five years earlier. Due to some creative programmer deciding to add five years to the current date in order to test for a five year record retention requirement a lot of things happened five years prior to the actual date. This subtle clue gave us the incentive to go over ALL the code in use with a fine tooth comb over the next five years and fix any such issues.
However,Upper Management decided that, on that fateful New Years Day, it would be ALL Hands on Deck regardless of whether they had any direct part in the five year project called Y2K remediation.
By noon on Jan. 1, 2000 it was obvious enough for even managers to realize that the apocalypse had not happened. However, for the first and ONLY time in my career I actually got paid for coming in that day!
The cobol cowboys to the rescue! (Score:1)
This is about fraudulent consulting, not Y2K (Score:2, Offtopic)
The story talks about "certifying fraudulent financial statements from Enron" and redundant documentation. These have nothing to do with Y2K, they would have happened with or without it.
It also has nothing to do with capitalism. Whether you love or hate capitalism, it's neither more nor less fraudulent than any other economic system. Humans will figure out ways to commit fraud regardless of the philosophy behind the economy.
Fake? (Score:2)
I recall seeing an article about a truck driver in Maine who bought a new truck in 1998 and recieved "Historical vehicle" plates because the DMV computer couldn't handle a 4 digit model year.
Most industrial software wouldn't care about the year. Accounting and finance though might have been a mess. What does your warranty system do if the records ssy the consumer bought the product 98 years in the future? That's trivial compared to interest calculations though - how much do you owe on your house if you boug
Y2038 is Coming, The End is Near, etc. (Score:4, Insightful)
Y2K issues were to be anticipated. Maybe not as far off as the Y2038 problem (32-bit time_t) but it was a known issue looming and getting kicked down the road. These are all just singular manifestations of using limited representations for time. The Y2038 problem bit insurance actuarial calculations years ago. Forecasts about a 30 year old's retirement trips the Y2038 problem today. The expected lifespan of a newborn tripped the Y2038 problem years ago. The horizon for the manifestation of the limitation depends on the application. Embedded systems with 20+ year life spans should have worried about Y2038 years ago.
This is not limited to Y2K and Y2038. The Boeing 787 had a time counter rollover which required a reboot every 248 days (https://betterembsw.blogspot.com/2015/05/counter-rollover-bites-boeing-787.html). FAA solution -- reboot every 120 days.
The Patriot Missile System had not a rollover issue but a conversion accuracy issue which led to a rapidly increasing inaccuracy in the tracking gate. (https://www.cs.unc.edu/~smp/COMP205/LECTURES/ERROR/lec23/node4.html)
It is my experience that the inherent limits in a system's base time and interval representations is rarely considered as a risk factor in system design.
Managing time on computers is hard. Whether it is time math, time synchronisation, or just keeping an activity on a strict timeline, they all present challenges when implementing a system.
Or D32k, for another obscure one (Score:2)
Andersen Consulting aka Andersen Insulting (Score:2)
Y2K was very real for many companies. I worked on newspaper circulation systems. Think something like the full SAP ERP solution specific for the newspaper industry. Newspapers were big things still back then and they had a big problem. When paid in advance subscriptions were to expire in the new millennium, the systems were going to fail when they year as 00 c
Book Sale (Score:2)
This person is writing a book. Its a great opportunity to rehash 25 year old debates. For those too young to remember, there were intelligent people stocking up on basements full of water and food in preparation for the collapse of civilization. In fact, its likely only intelligent people who read all the articles and knew all about the danger. That it was over-hyped was obvious. But there were some real potential problems and sorting those out from the media noise was not easy. And there was money to be ma
Their? (Score:1)
Leigh Claire La Berge (Author) is one person. The author's name and image are classically feminine. So, there are a couple of options here. We can rather safely assume "she/her", especially if the author doesn't specify something else. Or, if the author has provided something else, we can use the preferred pronouns. However, preferred pronouns as "plural"? No. It is NOT neutral. It is representative of plural. There are singular ambiguous pronouns that exist in the English language. We could say "
Re: Their? (Score:2)
All that and you finish with an apostrophe plural?
Before auto updates (Score:2)
The other thing to remember with Y2K besides all the code that was fixed was that most stuff didn't autoupdate back then. It was the OS, antivirus, and very little else. So someone would have to wander around and check versions (if they didn't have some kind of software inventory system in use) and do a report on what needed to be updated and whether that would cost anything, etc etc.
I knew of one tangible Y2K product (Score:2)
Namely, they sold a PCI card that was designed to help your BIOS deal with moving from 1999 to 2000. Granted I never purcha
Just like any real crisis (Score:2)
You have people who actually realize there is a problem and want to fix it. Y2K was indeed an actual problem.
Then you have people who are scamming because there's an emergency situation going on.
Sounds like the author was in a position in the latter. Who on the client side was quality control? Surely they own some responsibility as well.
So the author scammed people, and now wants to make more money by telling how they scammed people? Lol, people these days.
Y2K was not fake - I wish we'd let it crash (Score:4, Interesting)
Even after the first pass, he caught dozens of errors that would have shut down the phone and data backbone for days or weeks at Y2K, and MCI controlled 85% of the North American backbone at the time.
Several times, I helped him walk through the code, and we found bugs that would have effectively shut down vast sections of the network and made it nearly impossible to patch. Without the routing of the network, it would have isolated the very machines that needed updated software. When people tell me that Y2K was a non-event, I get visibly angry because we worked our backsides off to make sure it was a non-event, and in return, we get told there was never a problem to begin with.
It makes me almost wish we'd have let it all come crashing down because we could have leveraged that for the next ten years of over-priced salaries instead of what did happen, which was five years of some of the leanest and most brutal job markets ever.
That was our reward for a job well done: layoffs and salary cuts.
This Leigh Claire La Berge and her story aren't worth the "cow dirt" that the guy took up shoveling after his retirement (he raised cattle).
Re: (Score:2)
Many systems stored the year part of the date as two decimal digits, so it would interpret "00" as 1900.
Re: (Score:2)
It made the code simpler, which was less costly to maintain. In many cases it would actually be stored as text, and not integers, which would actually take the same amount of memory, two bytes. No one writing code in the 70's gave one bit of thought that their code might still be in use in 1999.
Once again ... (Score:2)
... the problem was real. And disaster was averted by ... get this ... fixing it in time.
Fine, maybe her job was fake, but the problem, and the fixing of it, were not.
For reference, see ransomware (Score:2)
When our huge health system was hit by ransomware recently, disaster did ensue. Some surgeries did get delayed, x-rays and other tests were taken but results never sent, etc. For weeks. Misery and chaos, for staff and patients.
Their attempts to "just do things manually and recover" were ... laughable. (Black humor, foxhole humor, laughable.)
That was just one organization, with a still functioning society all around it.
If we had just blown off Y2K and let things break first and only then tried to fix them
Hint: AI is the next Y2K (Score:1)
"Prompt Engineers" "Ethical Analysts" "Model Trainers" hahahaahahhahahahaa! OMG you hairless apes, such entertainment!
Still no Funny? (Score:2)
Story expires unlaughed at... Oh well. Not an obviously rich target for jokes. Or is Slashdot becoming slow-witted?
But in the end... (Score:2)
No Funny.
Dotcom bust and Y2K bust timeline (Score:2)
This made me wonder. The Y2K scare did make companies spend a tremendous amount of money. How much of that money made its way to propping up the dotcom boom?
When the Y2K scare and funding finally went away, the dotcom bubble went with it.
Re: (Score:2)
This is not about you looking at your own stuff. Obviously, that was (and is) a very good idea. This is about hiring one of the Big Four (back then the Big Five) to do actual work on an actual problem. And that is not a good idea.
Re: (Score:2)
Argghhh....that asshole is still out there generating gibberish that is promptly sucked up by Murdoch properties, namely the WSJ. If economic advice were food, his would be cyanide.