Engineering Judgment
Ron Graham
with Tim Wescott, Harley Myler, and Bob Kluck
I'm asking the question What is "engineering judgment?" because I see this expression used regularly in textbooks and trade mags, and hear it in conversations, without ever getting a definition. If I ask engineers in a meeting what they mean by this, they usually look at me like I've crawled out from under a rock. "What do you mean, what do we mean?"

I assume it means something like "making decisions in design and/or analysis based on past experience, not fully quantifiable knowledge about how a certain systems work, and perhaps a hunch here and there." That's sort of what happens when you apply simplifying assumptions to modeling of complex systems, like by

  • lumping parameters
  • small-angle approximations (and other similar techniques for ignoring "second-order" effects)
  • lossless pipes and wires
  • frictionless surfaces
  • constant material properties (in individual samples and in batches)

....that sort of thing. But nobody ever *says* that's what it means. And it kind of scares me that we don't, because we sometimes depend on this thing in decision-making. We make a decision, say it's based on "engineering judgment," and all we really do is leave out other disciplines from the process. Like we're in some kind of exclusive club or secret society.

What's really dangerous about the way this term is used is illustrated in Richard Feynman's Appendix to the Rogers Commission report on the Challenger disaster. Listen to what NASA says:

Historically this extremely high degree of mission success [a probability very close to 1, not actually based on flight history] has given rise to a difference in philosophy between manned space flight programs and unmanned programs; i.e., numerical probability usage vs. engineering judgment.

In referencing "engineering judgment," NASA appeals to history but does not actually *use* historical data. If they did, it would not be possible (or at least not reasonable) to say the probability of a Shuttle failure is as low as 1 in 100000. That's what bothers me. I think the use of the term generally disguises what we *really* do, because

  • we think others won't understand
  • we don't want to have to explain or answer questions
  • we have doubts about our own methods
  • we don't have doubts about our own methods, but we don't want them examined

...and none of those reasons seems to me to be very good. They come off as the use of jargon to tell an audience to "shut up and go away."

I could have missed something here -- after all, the sound judgment of an experienced engineer is essential to getting systems to work. But that sound judgment doesn't mean the same thing to everyone who uses it, and not everyone can use it. The validity of an expert opinion is based on the "expert's" training and experience, both in quantity and relevance to the problem at hand.

This can come up in the event a court has to decide whether it was appropriate for an engineer to bypass any more rigorous method. It is possible for written laws to lead to worse designs than an experienced engineer could come up with.

All professionals are expected to use judgment in their work. An engineer might take an "educated guess" on a possible solution, then verify it through

  • analysis
  • demonstration
  • inspection
  • similarity
  • testing

The judgment, or guess, serves as a starting point. We might avoid that step if the problem to be solved isn't very complex, or if the hazards of a bad guess are small. Even with small hazards involved, though, a conscientious engineer should be willing and able to recheck the guess if needed.

If "engineering judgment" is some sort of catch-all term that means something more complex or arcane than we have time or willingness to explain, we're shaking off the audience. Sure, it's better to dispense with the explanation than to dispense with the judgment. But are those the only choices we have? Ask yourself if there's a simple way to tell others what you're doing. You may find someday that they need to know.


[Table of Contents] [Previous] [Next]