hosting by

High-Tech Ransom and the Y2K Caper: Pay Me Now or Pay Me Later

By Bill Warner

When information about the Y2K "bug" first began appearing, I paid little attention. After all, those old legacy systems have been around for 30 years or more and are cumbersome, complex, and full of the patches, additions, fixes, etc. needed to keep them running. I did not begin to pay attention to this "bug" (yes, those are quotation marks; I'll explain shortly) until information began to surface that this was not really a "bug" at all in the true sense. Instead, it was more an arrogant, programmer-knows-best, deliberately made decision. The consequences? Businesses around the world are being forced to pay collective billions in ransom to correct the consequences of this decision.

Computer bugs are nothing more than the unintended result of unforeseen combinations of user actions and program code. Sometimes these inadvertent consequences are only minor annoyances, such as a character that you can't eliminate from a document, or an endless loop that you can't escape except by the ol' hard reboot route. Other times the bugs cause enormous problems, such as the shutting down of the East Coast's phone system for nine hours (in 1990), or the erasing of your hard drive. They can even be fatal, evidenced by the death of four people in Canada via machine-caused radiation treatment overdoses.

Software programs have always been expensive and time-consuming to debug. After all, to debug them completely would require the programmer to run through every possible situation the user might encounter and every corresponding response. (Hmmm, perhaps an infinite number of monkeys at an infinite number of debug tools . . .? Nah, not gonna happen.) So, we have all come to expect and understand that most programs contain bugs. Thankfully, despite the software business' increasingly sloppy and apathetic debugging efforts, most programs run well enough.

But this Y2K thing is different. Because of the deliberate decisions of the program developers back in the '60s and '70s, the date field does not typically include the characters needed to represent the century (20th, 21st, whatever). That's why, when the date changes to the year 00, pandemonium is expected to occur.

The big iron won't know how to interpret those 00s and may begin acting like HAL after an evening of banging down tequila shooters and snorting angel dust. When I began hearing that the reason for not including those two additional digits was convenience and cost, I really started paying attention to Y2K.

This situation isn't a "bug"; it's one of the most colossal snafus (remember, this word is an acronym) ever. And it came about not because there wasn't time or money enough to debug the programs sufficiently, but rather because of technological arrogance and the perceived need to save money (read cut corners).

In an article in the 2/16 TechWebNews, a retired programmer says, "We could have written programs in the 1960s and '70s that would work in the year 2000. But it was so expensive. No one would think of putting in the century. It was useless accuracy." Expensive? What looks expensive now? Useless accuracy? Right, try telling that to the thousands of businesses, government organizations, educational institutions, and other groups worldwide who have to spend untold billions to correct what the mainframe jockeys couldn't be bothered to address 30 years ago. Not to mention airlines and passengers all over the world who can't be sure what the air traffic control system will do when the big 00 arrives. By the way, I don't recommend flying to your new-millennium party.

This situation teaches us yet again that despite their claims of always knowing best, the technologists can't be trusted to make effective decisions that consider the long-term interests of their customers or of the industries or businesses in which they compete. The comments about expense and useless accuracy are typical of the technologist who believes he knows what's best for the customer, like the software companies who keep telling us that bugs are a small price to pay for inexpensive software.

What to do? First, for you technologists, remember that when developing products based upon new technology, you may in fact be developing something that is going to be in use for a long time, far longer than you may have intended when you designed it.
So you better completely think through the casual implementation and deployment decisions that you and your engineering staffs make on a daily basis. Today's acceptable kluge may metamorphose into tomorrow's technology show-stopper.

This perspective would have been very helpful early on when the airlines were just being deregulated and air traffic was beginning to expand dramatically. New minicomputer and communications technology could have been slipped into place with far less disruption, and at far less cost, than the huge bill the government and airline industry are going to have to foot for a whole new system soon. But because cost was the only major factor considered, the necessary software and hardware updates were continually pushed farther and farther out. Now we are stuck with an antiquated, patched together, and, in many places, vacuum-tube-driven monstrosity that will be colossally expensive to replace.
Oh, and it doesn't work very well, either.

The second point is for customers to start demanding that new computer hardware and software be freer of bugs than what we've been getting from the computer industry recently. This may result in products that are somewhat more expensive at initial purchase, but which will be far less expensive to live with long term. In effect, the computer industry now is foisting off upon its customers the hidden high price of its shoddy debug efforts at the home office. Because the software companies don't do their jobs effectively, they seduce us with cheap (in many senses of the word) products and force us to bear the costs of living with buggy software and hardware. Very clever. They reap more profits faster, yet force us to pay the time, anger, frustration, and dollars required to keep such buggy software alive and productive.

Today, we're no longer in the mainframe era, where DP ruled and system users had to accept applications in whatever klugy form and dubious quality the DP guys provided. Now the customer is queen, and she has a right to expect software to work right and to be more bug-free than it typically has been. That's why customers in the know insist on being able to Beta test new mission-critical software and wring it out before they commit to final installation and make those last payments to their systems consultants. They demand bug-free operation and the ability to upgrade their systems on a regular basis.

Remember how great the automated baggage handling system at the new Denver International Airport was going to be? Remember when Andy Grove told you it didn't matter that your Pentium processor sometimes couldn't do simple arithmetic properly? Who do you trust? And how much are you willing to pay?