I went to lunch with a former boss last week and we were talking about the ins and outs of learning from your mistakes and certifying a design. He works on electronics boxes and does a decent amount of thermal, torque and vibration analysis on every single box before it goes into the field. When one of his boxes was on a piece of equipment that catastrophically failed recently, they took it off and ran it on a shake table. Then they tested it again and it still worked. He told me he was criticized for having typically overdesigned boxes.

What does honey have to do with this? Well honey is one of the few foods (maybe only food) that if it’s sealed, unfiltered and without additives it can last a very long time. It never really goes bad, though it can ferment if not properly sealed. Engineers are always looking for the perfect solution of something having a long shelf life and being as close to unbreakable as possible. NPR just had an interesting story asking How Safe is Safe Enough? It was of course discussing the recent nuclear events in Japan and what determinations engineers use to figure out if something is safe.

Of course there’s no absolute value of safe. And certain contingencies will never be predicted and so can not possibly be designed for. But we always get a little better. New nuclear plant designs include failure-oriented design where if failure occurs the plant will fail in on itself and prevent catastrophic failure that would affect the whole area, instead becoming immediately useless once failure occurs. But too often the blame when a bridge collapses goes to the engineer who built it. That engineer may have never meant for the bridge to be operating decades longer than its supposed conditions, and how responsible must they be when politicians don’t fund infrastructure updates or build new bridges? Or if you take the recent 737 structural failures who do you blame, the structural engineer who didn’t foresee a private company would be using the plane much longer than its intended life?

Too often engineers are given limited tools and time to make something robust. Most engineers I know tended to err on the side of caution at one point in their lives. Once they got into management, and timetables or overly optimistic promises to the customer got involved, these instincts were dampened by the need to produce a viable and affordable product in a certain timeframe. And often engineers make tough decisions on extending the lifetime of various products. This is the new frontier, where you don’t have data to predict the future, but have to go off of past performance to make a safety call. And sometimes that engineer is no longer involved when the lifetime of a machine is being extended and the tribal knowledge and direct experience with that product is gone and people make poor decisions.

If we had unlimited time and money, we could make every single product with extremely high safety factors. But there has to be a line drawn somewhere, whether for cost, time, or simply probability and likelihood. How do you make these calls? At what point is your product overdesigned?

3 responses to “Can a design be too robust?”

Frau, excellent post. I can really relate to it. I wish we had the luxury of overdesigning. Rather, most of our products are quite underdesigned. Management asks us whether how much risk is there if we don’t do A or B in trying to verify our designs. Of course, we don’t really know if we don’t do a proper analysis, which takes time we don’t have. So the engineers give an equivocal answer which is then interpreted by management as having low risk. So the product goes out the door, runs into issues in the field, and gets returned with all the fingers being pointed at engineers.

I work in an industry sector where “design” tends to be a little more casual, focused more on mechanical fit than anything else, and tends to be based more on rules of thumb, gut feel, and even aesthetic, rather than calculations. I’ve worked at a couple of different companies in different ends of the same industry, and tradition seems to define the results. As a note, factors of safety in this industry relate more to component failure and warranty costs than to human safety.

Company A built their systems like tanks. You could probably cut 20% of the material cost (finer frames, smaller actuators, etc.) and still have a system that would more than meet the requirements. Before I left there was a drive to reduce costs, but going to a more involved engineering process to actually calculate the requirements to get to a “just good enough” system would probably have massively increased the engineering time, so that was discounted fairly early on. In a way, it’s the opposite problem to what’s described above – there it could be beneficial to reduce the safety factors rather than overdesigning through “efficiency”.

At Company B, the design standards are definitely less robust (and as a result have lower material costs), but this can result in damage to the equipment under unusual loading conditions (say, getting hit by a forklift, or poor preparation for transport). Spending the extra time to consider the unusual loading conditions would probably result in spending less on warranty, but the drive isn’t there to spend the extra time in design.

I agree on it as far as Management’s approach to design work. Also, they don’t apply all required resources on time. But the designer must be smart enogh to come over all such situations.

I feel, using over designed products is making us poor on part of availability of natural resources. Say for example, if an engineer designs a simple coupling for a pump and taken greater than required factor of safety or used what was not failed earlier (you say it time tested). It impacts on consumption of steel used for making such couplings. And if these couplings are going to be used for millions of pumps, your design will impact natural resources by few hundred tons……and so on….

A very balanced and producable design of everything is required to save the world from consuming unnecessary consumption of natural resources.