Put another way, almost three-quarters of all software development in the Internet era suffered from one or more of the following: total failure, cost overruns, time overruns, or a rollout with fewer features or functions than promised. CIO could run "Still Yet Another Trip to Hell" next month. The article could include Nike’s glitch with i2’s inventory software, which prompted Nike CEO Phil Knight to wail, "This is what we get for our $400 million?" It could mention Sobey’s, a Canadian grocery chain that in February suddenly and publicly canned an SAP project. (You could practically hear the sonic whoosh of $50 million following the press release into the trash bin.) Or it could tell the tale of a 100-year-old management consultancy that, according to an inside source, spent tens of millions on a failed ERP deployment, then tried and failed again after sinking another $8 million into the black hole.

But what would be the point?

A litany of failures and maddeningly familiar advice?Nike needed to test more; Sobey’s needed a project sponsor; the consultancy should have killed the project?simply restates what everyone already knows. The problem isn’t with the advice; the advice is sound. The problem is bigger. The problem is the development methodology itself. The problem, says Martin Fowler, programmer and cofounder of The Agile Alliance, is that companies construct software much the way people build bridges. (And Fowler should know. His wife, Cindy Chabot, is a structural engineer. Bridges are what she builds.)

Why Building Software Is Not Like Building a Bridge

A bridge begins with a blueprint based on mathematical certainties and predicted levels of tolerance that never change. The blueprint is followed precisely. Changes are costly and therefore anathema. The tools used to build the bridge are standard and don’t change during construction. The materials are familiar and behave predictably.

Because of all that, we’re pretty good at building bridges. They rarely fall down.

But bridges are built to do only one thing: connect two pieces of land so that people can cross between them without falling. Software tries to do many things, and many of them have never been tried. And the tools used to build the software change continuously.

Therefore, as long as software engineers act like bridge builders, they are doomed to fail. And the cost of that failure is beginning to rise.

"If this were the pharmaceutical indus-try, we’d be killing people," says Joshua Greenbaum, analyst at Enterprise Applications Consulting in Daly City, Calif. Greenbaum tracks ERP, the clay pigeon of software failure stories. "There’s no reason to tolerate this level of failure. It tars the software industry. And frankly, it’s bad for the CIO."