Some economist analyzed all of the leveraged buyouts of the 1980s and made a startling discovery: In about 70 percent of the cases the companies — generally profitable when acquired — did not generate enough cash to pay off the debt taken on in financing the LBO.

Everyone involved in these transactions knew they would fail, but it didn’t matter, since they all ended up wealthier than when they started.

Why do groups of people who are individually smart seem to act stupidly so often? A group is smart when its members’ personal short-term interests coincide with the group’s long-term interests. Otherwise the group will do stupid things.

That, far more than a bunch of dumb CIOs caught off-guard when a century sneaked up on them from behind, explains why we have a huge year-2000 problem.

The year 2000 is a crisis because until it reached crisis proportions, making this year’s numbers was more important than investing resources in surviving past 1999. Understanding these dynamics should change how you set IS priorities.

I remember raising the year 2000 question back in 1994. We spent exactly one sentence discussing it. Since we lacked the resources to satisfy immediate demand, the year 2000 could wait until 1995, when with luck we would all have different jobs and it would be someone else’s problem. (No, none of us actually admitted to that thought process … maybe I was the only one that shallow.)

What problems do you have with your systems architecture or applications portfolio that you could fix with little stress if you started right now? I’ll bet you have at least one.

Maybe your particular problem is an ancient system with old, fragile code nobody really knows anymore. You can fix it by rewriting modules that require maintenance instead of simply tweaking them, even though the rewrites will take twice as long.

Or maybe you operate a batch legacy environment, and you know in your bones that the company needs to operate in real time. Figure out how to switch one class of updates at a time from the batch queue to online transaction processing and incorporate this into your overall IS strategy.

Use your year-2000 crisis as a lever to sell a long-term program of technology grooming, so you never again experience this kind of difficulty. I know that right now, if you’re a typical CIO or IT director, the year-2000 problem seems like your greatest challenge and these other projects seem distant at best. And I have almost no useful advice to give you on solving your immediate problem except for these very obvious points:

  • Make sure you have enough programmers assigned to the project. Then add a few more for good luck.
  • Assign or hire the absolute best project manager you can possibly find and afford to run the project.
  • Pay more attention to testing than to any other part of the project.

The immense cost estimates for the year 2000 fix are misleading. Yes, organizations will spend huge sums. These sums will have little adverse impact on the economy, though, because for every company that spends there are others, or individual employees, who receive.

The real impact of the year-2000 problem will be to reward far-sightedness: Competitors that have already fixed the problem can now afford to invest in projects that yield a competitive advantage.

People get all excited about the darndest things.

I know otherwise normal people who froth at the mouth when they hear me say the millennium starts Jan. 1, 2000. No, they insist angrily, it begins Jan. 1, 2001. Don’t I know anything?

Well yes, I do. I know it’s more a matter of opinion than the hard-liners think. Why? Let’s begin with a startling realization: Decades and centuries don’t line up!

Decades, named by their first year, number 0 through 9, so the 1990s are named for the year 1990 and end Dec. 31, 1999. Very few people claim the year 2000 is part of the 1990s.

Centuries number from 1 through 100. That makes sense — this is, after all, the 20th century, so the year 2000 had better be a part of it.

The question of when the millennium begins, then, all boils down to this: Does it begin with a new decade or a new century? I say it starts with the new decade, in 2000. You’re free to wait until the new century begins, but I’m guessing you’ll miss an awesome party on Dec. 31, 1999.

And you won’t get to attend one the following year, because the world will, of course, end in the year 2000, destroyed by ubiquitous computer failures.

Just kidding. As it always does, the world will muddle through, saved by a mixture of planning, hard work, and improvisation.

I call this column the IS Survival Guide because survival is quite an accomplishment for the working CIO. Surviving the year 2000 will be quite an accomplishment.

Two big myths surround the year-2000 problem. The first is that it’s a bug. The second is that it’s a mess because somehow the end of the millennium snuck up on unwary CIOs all over the world.

Let’s explode these myths right now so you can focus on solving the problem instead of avoiding the blame.

The way we encode dates, or at least used to encode dates, was an intelligent design decision back in the 1960s and 1970s when in-house and commercial programmers wrote most of our legacy systems. Storage — both RAM (we called it “core memory” back then) and disk — cost lots of money, and the best programmers were those who could squeeze the most performance into the smallest computing footprint. Saving 2 bytes per date field made all kinds of business sense, and nobody figured these systems would have to last three decades or more.

They’re still running, either because we failed at our grandiose replacement projects (I’ve seen several of these) or because there simply has been no compelling business reason to replace systems that work just fine.

That is, it really is a feature, not a bug, and it proves once again that no good deed ever goes unpunished.

Here’s who will be punished: You, for not starting to fix the problem several years ago. And it isn’t entirely your fault.

I remember asking in 1994 whether we had any year-2000 problems, when just a few worriers first started to write about the subject. It didn’t matter. We had a tight budget, had just reduced staffing 10 percent to help the company improve its short-term profitability, and had the usual laundry list of urgent projects. The millennium would just have to wait a year or two until it became urgent.

Business has a short-term focus because Wall Street drives business strategy, and Wall Street insists on quarter-by-quarter earnings improvement. Fixing year-2000 software problems adds no new value, so until the problem reached crisis proportions last year, few companies bothered to spare any resources to fix it.

There’s plenty of blame to spread around, but let’s not. Instead, next week, we’ll look at some lessons we can learn from this fiasco.