It’s true, but I really understand why many people don’t think it was a real thing. LOL, if I hadn’t had to immerse myself so deeply in it for so long and unpleasantly, I might have thought so too.
I frikking hated it...we had multi-week meetings with up to forty people at it, and gad...I remember thinking “Come on-why can’t we just FIX the issue?”
Well, we couldn’t just “fix” it, it was wormed so far down in this legacy application that rooting out all the branches was a real chore. I learned a lot during that year and a half, I can tell you. I worked side by side with one of the two women who actually wrote most of the program, and that was invaluable to me.
From her, I learned everything about how to draw up and execute a comprehensive and bulletproof test plan, which means that I own that to this day...:) She warned me, too. She said nobody likes doing this part of the job, and if I was good at it, I would get “volunteered”...which is what happened. It can be nasty and tedious, but it is great when you can do it well enough so that when you go live with a new system or an upgrade, it isn’t as “exciting” as it can sometimes be without a good testing regimen!
Part of the Y2K thing was, that the years of hysteria leading up to it DID make people think everything was going to go dark or become non-functional.
I was one of those people who were up all night watching things...and boy, was I relieved.
I was glad it was perceived as a nothing-burger!
This software engineer thanks you!
In the end, it all worked out because we had the best OCD people working on it.
Indeed. A lot of people worked long hours to make sure things worked correctly. At the time the project manager for my company's Y2K project was in an office right next to mine... I often wondered if she ever got any sleep.
I worked my butt off in the couple years leading up to it… patching hundreds of small business and personal PCs as well as running down custom built software that had it built in. We made it a nothing burger through hard work and diligence, finding the hidden time bombs.
I got called by a used car dealer who tried a test by setting his computer to January 3, 2000, and found his software that printed all the sales contracts AND did all the registration for the DMV for selling a car claimed the car was being sold and registered on 01/03/1900! The software put that bogus date in every place on the contracts, registration, bill of sale, etc… and there’s a mandatory FINE assessed by DMV for every single error on those documents, regardless of why they were made, including typos. It calculated payment dates and payoffs, etc., using dates for the early 20th century, and screwed up the leap year for 2000 (2000 didn’t have a leap day, while 1900 did) throwing off another issue of every car being sold one day earlier than it actually was sold, creating the appearance of fraud. Since the publisher was long gone and no updates were available, he and all the other dealers who used that software were going to have to buy and learn to use new software on very short notice. Many after they discovered the problem after the new year and they could not legally transfer the cars they sold without incurring huge fines or requiring their customers to laboriously go through every single page of the error laden printed papers, and initial every single corrected date change from 1900 to 2000! And still run the risk of having the State DMV reject the entire package which is supposed to have no corrections or deletions!
I was able to patch his software as he did not want to shell out $16 grand for a new used car software package. I found the code and fixed his package, and then i was able to offer the fix to quite a few other dealers who used the same package once i showed them what was going to hit them! I made a tidy sum on that…