I’m having another go at learning Visual Basic not that I’ve had any problems with it in the past. It’s just that every time I get ready to try my hand, my employer has said “Never Mind” and everything on the subject that I’ve managed to stuff into my wee sma’ brain escapes. My current part-time gig uses VB & ASP.NET extensively so I’ve signed up for a course and am getting ready to do it one more time.
Anyway, I’m reading a book called Learning Visual Basic . NET and I can tell that the author is somewhat younger than I am. I found the following footnote:
Remember, the Y2K problem was caused by programmers who couldn’t imagine needing to reference a year later than 1999.
A fine example of youth and inexperience that is. The Y2K problem really began in the early days of computing when memory was tight. The machine I worked on after graduating from Wesleyan had only 16 K of memory. There was a mainframe on site that had an incredible 256 K of memory! In the early days of computing, machines had a very limited amount of memory so the coding for an application had to be tight and every byte of storage had to be conserved. Why waste a byte for “1984” when “84” would work just as well. The Y2K mess was due to the fact that there was no remediation of data and applications when hardware began sporting larger amounts of memory, well before the turn of the century.
I saw the problem coming back in 1981. The general assumption was that these older applications would be superseded with ones using more modern programming techniques as time went by and thus the problem would simply go away. Trouble is, it didn’t. While it became standard to use “1984” instead of “84” in an application, a lot of the old data – and the systems that depended on it was still using the old method for designating a year. Add to that the fact that significant amounts of code were still in use a quarter century after it was first written and you have Y2K. Q.E.D.
The year 2000 dawned and there was – overall – very little disruption due to the world’s odometer ticking over. There followed a hue and cry from the general public that the whole Y2K problem had been overblown and was essentially a case of crying “Wolf”. Rest assured that the problem and threat was very real. Things went smoothly because a bunch of software engineers – including yours truly – spent a lot of time remediating both code and data to ensure that disruptions would be kept to a bare minimum.
And now you know the rest of the story.