Columns

There's no success like failure

• By Jack Vaughan
• January 1, 2002

An obsession with failure could be a problem, but a modicum of fear of failure—a respect for the phenomena that can undo a design—may be healthy in a designer or developer. Maybe you should hear out a job candidate who is capable of analytically discussing a failed project or two.

If you are wary of this advice, I don't blame you, but you might be more inclined to follow it if you were to hear from Henry Petroski. This Duke University professor of history and civil engineering spoke at last fall's OOPSLA Conference in Tampa, Fla. In a kick-off keynote address, Petroski discussed success and failure in design throughout history, concluding that there is a unique interrelationship between the two.

"All materials are flexible if slender enough," asserts Petroski, who noted that designers in bridge design tend to go toward the sleek and aesthetic as they get further away in time from the first principles. The Tacoma Narrows Bridge breakup of 1940 stands—well it doesn't exactly stand, it fell—as a testament to Petroski's assertion.

Scholar Petroski took his OOPSLA audience back to ancient Rome to make his point. He discussed Vitruvius. That author of key architecture texts went to great length to consider failures of stone-and-axle variations (that's how they moved pillars) of the day. Vitruvius suggests that following a successful design to an ultimate conclusion is not the way to proceed.

"Ships a-scale"
The big ships, many failed, of the era of European exploration came in for consideration. "Ships made of wood were scaled up, every dimension doubled," said Petroski. "At a certain size, they would break in two."

Petroski noted that nature does not design this way (to blindly scale up); the leg bones of large and small animals are not exactly proportional. Cable stay bridges are now the rage in bridge design, noted Petroski. Their design is becoming increasingly ambitious, he added, and some failure may be in store.

"Failures in bridge style seem to repeat in 30-year [intervals]," said Petroski. "Engineers are ambitious. Everyone wants to build the largest bridge in the world. Cable stay bridges are exhibiting problems."

Whenever the envelope is pushed, he indicated, "there is opportunity for phenomena to manifest that were not obvious in the small."

Failure could be generational, said Petroski; when engineers start to work with new design paradigms they take great care. Then as things get familiar, they forget about the fundamentals and they push, sometimes beyond the real design limits.

Where are there examples of failed designs in recent software systems history? Petroski does not speak to this point, but we can suggest a few. As a general class of design, client/server computing is a fairly recent case.

Two-tiered client/server systems worked well up to a point, and then became overstressed as systems grew. If you scaled it up linearly, it failed. The software industry has a marvelous way of introducing the next fair-haired star just as an earlier one becomes tarnished, and client/server was replaced by Web-centric computing before its problems were really solved.

How will we look back at American industry's recent venture into the realm of Web-centric computing? This skeptical examiner would hold that the niggling client/server issue of distributing a desktop GUI was solved, but only temporarily. Sometimes a thin client is not the way to do business. Meanwhile, legions of developers will continue to need to produce scripts to keep Java Server Pages churning, all in the name of the thin ubiquitous client. People will do this until they get tired of it, or until the paradigm is certifiably broken.

Throwing hardware
One could also suggest that some Web systems were over-built and under-designed. In the push to embrace a Web economy in Internet time, a lot of hardware was thrown at a lot of problems. Will these systems need more hardware to cope in the months to come? Will there be money for such updates?

Grant for a moment that we may not have fully understood Web computing issues and then contemplate the fact that we have already set sail for a new paradigm, that is, Web services. The Internet was built to withstand a nuclear conflagration. But mightn't the Web, under the throes of Web services, meet another fate—to be pecked to death by ducks?

At an OOPSLA conference panel on the future of distributed objects (which pretty much was a discussion of Web services), a reporter asked if any of the panelists ever worried that Web services designers might not overburden the Web infrastructure and break it, in much the same way as an overly ambitious design broke the Tacoma Narrows Bridge. Several panelists answered with an unexpanded-upon "yes." Perhaps failure is an option, but not one many want to dwell on.

Is there value in studying failures? Send me an e-mail at jvaughan@ 101com.com and let me know what you think.