341–350 of 385 posts
The media did sensationalize it with stuff like "Planes falling out of the sky!" but there would have been massive disruptions due to systematic date/time issues. Tons of money was spent testing systems to ensure they're Y2K compatible and if not these systems were either patched or hastily replaced with something that was.
Yes, the y2k crisis was real, or more accurately, would have been a serious crisis if people had not rushed and spent lots of money to deal with it ahead of time. In many systems it would have been no big deal if unfixed, but there were a huge number of really important systems that would have been a serious problem had they not been fixed. Part of the challenge was that this was an immovable deadline, often if thing…
And the dotcom bust came when it did in part because the Y2K spending was lifting all boats. A bunch of companies shifted from buying too much to buying not much.
Earlier quoted context omitted.
>dbase At the time I was managing a dBase / FoxPro medical software package...we were a small staff who had to come up with Y2K mitigation on our own. Our problem is we only had source code for "our" part of the chain...other data was being fed into the system from external systems where we had no vendor support. Thus our only conceivable plan was to do the old: If $year It worked in 99.9% of the cases which was enou…
A much more insidious problem with the Y2K bug was the leap year calculation. As you point out, the 20-digit-year thing was relatively easy to fix. https://en.wikipedia.org/wiki/Year_2000_problem#Leap_years
> This method works fine for the year 2000 (because it is a leap year), and will not become a problem until 2100, when older legacy programs will likely have long since been replaced.
Yes, the y2k crisis was real, or more accurately, would have been a serious crisis if people had not rushed and spent lots of money to deal with it ahead of time. In many systems it would have been no big deal if unfixed, but there were a huge number of really important systems that would have been a serious problem had they not been fixed. Part of the challenge was that this was an immovable deadline, often if thing…
From what I've heard, a number of IT departments used it as justification to dump legacy systems. For example, at a former employer of mine, a big justification for getting rid of the IBM-compatible mainframe and a lot of legacy systems which ran on it (various in-house apps written in COBOL and FORTRAN) was Y2K. In reality, they probably could have updated the mainframe systems to be Y2K-compliant. But, they didn't…
> In reality, they probably could have updated the mainframe systems to be Y2K-compliant.
Legacy systems weren't always mainframe systems and, in any case a “legacy system” is precisely one you are no longer confident you can safely update for changing business requirements.
A change in a pervasive assumption touching many parts of a system (like “all dates are always in the 20th century”) is precisely the kind of thing that is high risk with a legacy systems.
Earlier quoted context omitted.
It was also really difficult to detect bugs since no good testing paradigms had been established yet. This created an exploitable opportunity for the few who knew how to write automated tests. During the Y2K panic Sun Microsystems (IIRC) announced that they would pay a bounty of ~$1,000 per Y2K bug that anyone found in their software (due to the lack of automated tests, they didn't even know how to find their Y2K bug…
That's a fantastic story, I'm impressed the professor didn't try to take the whole settlement.
Earlier quoted context omitted.
Yup. It's funny, because for the first 2/3 of my tenure there, WalMart Information Systems Division did move extremely fast....and yet almost never broke anything. It was an amazing thing to see.
Story I heard from someone who was at Walmart recently was that the surest way to get in trouble was to finish in a week what they had planned to take three months.
My contacts over the past 11 years have said that the division has continued its slide into bullshit.
Given how fantastic things were, it makes me very sad.
Earlier quoted context omitted.
Yup. It's funny, because for the first 2/3 of my tenure there, WalMart Information Systems Division did move extremely fast....and yet almost never broke anything. It was an amazing thing to see.
Sounds like a very listenable collection of anecdotes and war stories. I would be very interested if you ever share :) (You're almost certainly already aware of http://old.reddit.com/r/talesfromtechsupport - but just in case. And hint hint.)
I was aware of /r/talesfromtechsupport but haven't frequented it much. I will take another look.