Why 2K ? - Part 1

Let’s start out with a little computer horror story. In the late 70's, while employed as a mainframe programmer, one of my first assignments was to act as part of an ad hoc team assembled to fix the 1980 Decade Bug! Yes, many of the programs in that corporation could not even handle a decade change, much less a century change. While articles today are whining about the difficulty of dealing two-digit years, we were facing one-digit years!

Now for the really scary part - our specific assignment was to apply a decade-specific emergency patch that would allow the program to be run ONLY during the1980s! Let’s see now. When faced with the shortsightedness and possible downright incompetence of their predecessors, information systems management chose to - you guessed it - add yet another layer of incompetence! And no, this wasn’t just any plain vanilla company. This company was a combination computer service bureau/computer consulting firm/computer facilities management firm. Note that the operative word here is "computer". All of the employees, from the president on down, were computer literate, and the vast majority of them were computer professionals. In other words, there were no excuses that could have been made regarding non-computer managers interfering with computer-related tasks.

Well, orders are orders, but ethics are also ethics, so, not being too fond of the Nuremberg Defense ("I was just following orders."), I did some research on date handling (the fiscal kind, not the relationship kind). After examining some existing programs, asking more experienced colleagues, and spending some time (my own) at the 70's equivalent to the World Wide Web - the local library - I came up with an algorithm (geekspeak for a formula) to handle all dates up to the year 10,000 correctly, at which point, it would run out of digits. It was an easy task, once I had the appropriate information.

With the algorithm in hand, I proceeded to examine the group of programs assigned to me. What I found was worse than expected. The programs written in the 60s already had a decade-specific patch to handle 1970! Even if I’d wanted to, I couldn’t have applied the ordered patch - there already was one there. Just to make things more interesting, I also found a few post-1976 programs that couldn’t handle a Leap Year! I fixed all of them, even the ones that would have worked through 1999.

What did I get for my extra effort? I got yelled at. No, to be more accurate I got YELLED at. The Director of Information Systems took me to his office and absolutely blasted me for not following orders, for not being a team player, and, most of all for wasting the company’s valuable time and money in taking the extra time to implement and test the more complicated, thorough fix even though the programs involved would "obviously" not be used for more than another couple of years before being replaced

Hmm. I’ll bet that’s what they said ten years prior when they installed the "temporary" 1970 patch that I found in some of those programs. Oh, and in case you are wondering, I ran into a manager from this former employer in 1996 and he confirmed that they were still using lots of programs that were "obviously" going to be replaced in the early 80s.

Now, it’s time for a little quiz. What was the common factor, the common word, the theme used in describing changes to programs in the passage above? The magic word is "patch" with some points given to those who selected the related word "temporary". These words describe the underlying theme of the computing industry - the idea that much of the day-to-day work is just a temporary, "quick and dirty" patch.

Complete programs and even suites of programs are written based on the idea that they are temporary stopgap measures that will, when the immediate crisis has passed, be quickly replaced with more carefully planned and tested programs. Ah, but when one crisis passes, the next materializes, as if predestined, to take its place, so the replacement or at least reworking of the original quick and dirty programs is put off again and again, until the project is finally forgotten.

Much has been made of the original reason for shortening the date, space considerations, but by the 70s, mainframe languages could compress the two extra year digits into one byte of storage. Mainframes were also well on their way in the transition from cards to tape and disks as primary storage, so that extra byte (or even two) wasn’t nearly as important as it originally was. There’s more to the problem than just space for extra digits.