Associating our year 2000 misfortunes with software bugs is widespread. My browser turned up 2,914 articles when searching for the "year 2000 bug" text string and 692 articles when inquiring about the "millennium bug."

How did the term "bug" catch on, when there are more accurate terms such as "screw-up," "negligence," "carelessness" or "thoughtlessness"? The answer is plain: A bug is an unpremeditated and unplanned occurrence, while the more appropriate words may call for a judgment about personal accountability.

The term "bug" goes back to the late Rear Adm. Grace Hopper, who often told the story about a moth trapped inside the mechanical switch of one of the earliest computers. She told the senior mathematicians a bug had caused the computer to malfunction.

Though moths could never block programming logic, the term "software bug" caught on. Programmers attributed all sorts of omissions and errors to bugs; it was a convenient term -- short and blame-free.

The word evolved, allowing the substitution of terms such as "debugging" for program testing. Today, we see software faults labeled as accountability-avoiding features -- as in President Clinton's Executive Order of Feb. 4, creating the Year 2000 Conversion Council for safeguarding U.S. government computers. It refers to the year 2000 problem as a "design feature."

But nothing in the history of computer jargon compares with rationalizing managerial negligence as a random event. Calling the year 2000 fiasco a bug suggests something as blameless as a trapped insect. It isn't. It wasn't an error of omission but an error committed because managers weren't diligent about the likely consequences of the systems they built.

Seeking absolution through fiction

Those who talk about the year 2000 situation as a manifestation of IT's supposedly intrinsic "bugginess" are following a well-established pattern of behavior. Psychiatrists have written books about the universal tendency to engage in blame-displacement when people are confronted with a mess.

The U.S. Air Force, for instance, has a long tradition of attributing to gremlins the responsibility for maintenance mishaps. Greeks and Roman generals would lose battles because of demons. Jewish lore is full of stories about dybbuks that make people do all sorts of things they later regret. The Irish deploy leprechauns, and the Scandinavians have their trolls to account for whatever mischief may happen.

We now face the most costly technological mistake since Roman engineers installed lead pipes that gradually poisoned much of the population of ancient Rome. The difference is that the Roman aqueduct builders didn't know, at least initially, the consequences of what they were doing. IS managers can't claim ignorance or blame fictitious creatures as a defense.

The explanation

Unfortunately, no one can learn anything if he's unwilling to comprehend. The time has come to understand why analytically minded experts would neglect fixing something that in due course would cost untold billions. We must be candid about it rather than hide behind a convenient bug label.

How the year 2000 neglect crept in and how it compounded isn't a mystery: The demand for IT support always exceeds available resources. Projects with short-term payoffs -- such as fast maintenance fixes and buying attractive new technologies -- look more appealing than long-term investments. When management confronts a choice between quick fix or quick payback -- as many consultants promise -- rather than the farsighted view favored by IS management and some vendors, the long-term approach doesn't get much of a hearing. Management trusts the consultants more than its own staff. That's how everyone ends up spending trillions of dollars in a continuous frenzy of build-and-scrap cycles.

The year 2000 problem covers up hundreds of other cases of accumulated neglect that show up as decreased employee productivity, increased overhead and unnecessary complexity. If we are to learn from the year 2000 experience, we must see it as a lesson in managing IT with an eye on its long-term consequences. Systems have a surprisingly long life, databases last for decades, and software logic is potentially immortal.

Software is an investment, not an expense. Treat it that way. Nobody will learn much from rationalizing it as a bug-prone accident.