> home
> About
> Contact Us
> Editorial Info
> IEEE-USA

06.10

When Designers Should Say "No"

BY DONALD CHRISTIANSEN

Faced with a design challenge, whether it be to refine an existing product or system or to meet some ambitious new demand, the usual procedure is to itemize the desired new design features—that is, the “needs” and the “wants.”

However, while this approach may yield a product that meets all the specified objectives, it may also yield some unwanted side effects. Such negative outcomes suggest that in addition to the positive aspects of a design, those things that cannot be permitted (think unanticipated acceleration that is not controllable, as in the recent Toyota recall) must also be specified. In other words, “don’ts,” “nos,” and “absolutely nots” should be added to the needs and wants menu at the outset of a design. If this is not done, it may be left to the reliability professionals and failure analysts to step in at some later date when serious systems failures have already occurred.

Why is it that features of a design that should not be permitted are too often overlooked? Christopher Alexander, a professor at UC Berkeley, addressed the issue in part when he compared the difference in design by users with that of design by professionals. Design by users would be, for example, the design of early dwellings or other structures by those who would build and then live in or otherwise use them. A top priority for these user-designers would be to end up with a structure that did not give them certain specific problems—a roof that did not leak, for example. But with the advent of architecture as a profession, “self-conscious” design features, as Alexander termed them, became important, and one would then not be surprised if Frank Lloyd Wright were to design a prize-winning structure whose roof leaked badly. The no-nos of the user-designer had taken a back seat to the ambitions of the professional designers. Today’s complex technology hardly lends itself to design by users, thus anything that should not be permitted in a design falls to the pros to determine.

It may well be that more attention was paid to avoiding serious negative design effects at the very beginnings of our engineering professions, largely because limited experience with technologies had left exposed the most obvious weaknesses in new designs. A classic example is that of steam boilers, which in the 19th century were widely used in factories, steamships, and steam locomotives. Boiler explosions would occur for a variety of reasons, involving not only weaknesses in design of the boiler itself, but also firebox construction, fuel explosions, and faulty safety valves and instrumentation. Not surprisingly, reducing the likelihood of explosions became a top priority in new boiler system design. By 1911, design improvements had resulted in the development of codes and standards for boiler specifications and construction, and the incidence of boiler failures dropped sharply.

Existing Systems

Large systems, especially those made up of several legacy systems that are loosely connected via both computer and human interaction, present a particularly difficult design update/modification challenge. The U.S. intelligence network is a case in point. Following the 2001 terrorist attacks, its various entities were charged with improving the collection and interpretation of security-related information. Yet the Christmas 2009 airline bomb plot was not detected despite pertinent information collected by officials of the National Security Agency, the National Counterterrorism Center, and the CIA. The systemic failure, as reported by The New York Times, occurred because no single person or even unit was in charge of following every high-priority alert. More than 80 databases were available to the National Counterterrorism Center. Two of its teams were working on separate parts of the same problem, yet failed to collaborate to bring together clues about the imminent attack. In retrospect, the “no” in the post-9/11 design of the system perhaps should have been “Do not permit the continuation of a system the parts of which communicate poorly and in which competition among its units is encouraged or allowed.” (“NCIS” watchers may sympathize.)

Under this same rubric I am tempted to mention the design of a counter-cyber-warfare program, but its required specifications are so far beyond my comprehension that I will leave it for another time.

Fixing a Bad Design

A known failure mechanism within an existing system that would lead to a catastrophic failure ought to be high on the list of “nos.” Such a design flaw was detected early on in the history of the Space Shuttle program, but it was treated with less than satisfactory design “fixes” with the consequent explosive loss of the Challenger and its crew. The lesson was not learned, and a second known design weakness led to the breakup of the Columbia Space Shuttle with all astronauts aboard.

Surely not all undesirable outcomes are unforeseen or lightly dismissed. The prevention of blowouts in oil drilling rigs has consistently been given top priority by their designers, yet the blowout-prevention valve failed in the offshore Louisiana disaster in April 2010. In less dramatic cases, certain expected failures are tolerated. With appropriate advice from risk and cost/benefit analysts, one hopes they occur with due warning, permit graceful degradation rather than catastrophic failure, and are not life threatening.

The Bottom Line

Engineers may deservedly get accolades for their optimistic can-do approach to design challenges, yet overlooking the must-not-dos can be threatening to the ultimate customer and/or to the general public, and potentially career-damaging. One designer remarked that avoiding one serious flaw is far more important than adding several glitzy new bells and whistles. But, he added, his bosses don’t always agree.

Resources

• Chase, R., “Driving by the Numbers”, The New York Times, 12 March 2010.

• Alexander, C., Notes on the Synthesis of Form, Harvard University Press, 1964 (current edition, 2002).

• Hewison, C. H., Locomotive Boiler Explosions, David and Charles, 1983.

• McEwen, A., Historic Steam Boiler Explosions, Sledgehammer Engineering Press, 2009.

• Lipton, E., E. Schmitt, and M. Mazetti, “Review of Jet Bomb Plot Shows More Missed Clues,” The New York Times, 18 January 2010.

• The Joint Operating Report, United States Joint Futures Command, 18 February 2010.

• Christiansen, D., “Accidents Waiting to Happen,” Today’s Engineer Online, October 2003.

• What Went Wrong (a special issue on system failure), IEEE Spectrum, October 1976.

• Vaughan, D., The Challenger Launch Decision, The University of Chicago Press, 1996.

• Columbia Accident Investigation Board Final Report, Aug. 2003 (www.caib.us).

• Bell, T. D. Eby, J. Larrison, and B. Ranke, Blowout Prevention, 4th Ed., University of Texas, www.utexas.edu/ce/petex.

• Practical Well Control, 4th Ed., University of Texas, www.utexas.edu/ce/petex.

Donald Christiansen is the former editor and publisher of IEEE Spectrum and an independent publishing consultant. He is a Fellow of the IEEE. He can be reached at donchristiansen@ieee.org.