Last year at this time my staff and I were bundles of nerves. Oh yeah, we had spent much of the year and many hundreds of thousands of dollars getting ready for the BIG DISASTER, but still, we didn't know how well everyone else had done. We felt our code (all million or so lines of it) was very tight as we had done everything that we needed to do.
We had examined every line of code using automated programs, found and fixed every date issue and we even tested our entire system over 100 times over the new year on our duplicate disaster site. We had a backup generator and we were all on call on New Years Eve.
I was glued to the television as the new year rolled in over the planet. I had a feeling of tremendous relief as I realized that the big disaster was not going to happen. The phones still worked, the electricity still flowed and the missiles were not launched!
I remember how angry I got as I read the newspapers the day after. The papers all claimed the event had been hyped up and was a false emergency. They said we all got duped by programmers and consultants who wanted to make a buck off the supposed emergency.
We (my staff and I at the least) had worked very hard to ensure that the big disaster didn't occur. We knew with our company at least that the disaster was not overplayed. Without changes our computers broke, and they broke bad! With the changes they worked great.
We know that if we had not worked so hard before Y2K our company would probably not have had a good new year. We system managers, at least, would have been very busy and very unhappy indeed.
Interestingly enough as the new year and the real end of the millennium approaches, we have run into quite a few date problems. These are not related to Y2K (of course). They are the result of sloppy programming and improperly coded date routines. However, they serve to remind us of the vast amount of work that we did to ensure that we remained in business last year.
Unless otherwise noted, all photos and text is Copyright © Richard G Lowe, Jr.