Bench Talk

Tacoma Narrows Bridge. 

Apollo 1. 

Space Shuttle Challenger. 

Chernobyl. 

Mars Climate Orbiter. 

Throughout human history failure has been a bittersweet fact of life, and engineering is not exempt from this truth. Despite our best efforts (and sometimes, because of the lack thereof), engineering failures occur. The aforementioned examples are just some of the most highly publicized engineering disasters of the last 75 years. Sometimes, as we push the envelope in pursuit of success, things go horribly wrong. However, engineers should never use the reasons of those failures as an excuse. Instead, a failure should be viewed as a call to action, which brings with it the necessity to keep pursuing the root cause(s) of the failure. By doing this, we expand our knowledge and can reduce the likelihood of another disaster occurring in our future endeavors. 

The engineering profession has the strongest ethical obligation to public safety, second only to perhaps the medical profession. As an engineering student I was required to take an engineering ethics course. One of the most fascinating aspects of that course was reading case studies and doing our own “engineering forensics” to determine the root causes of the failures we studied. I recently pulled out my old class notes in preparation for writing this article. What struck me was how very similar the root causes of those major engineering disasters are to the root causes of the more ‘simple’ project failures we encounter as makers and DIYers in the pursuit of our OSHW dreams. Though the consequences are scaled down, frying a 555 timer chip is still disheartening (trust me I know!) So with that in mind, let’s take a look a some common root causes of engineering failures, some mitigation strategies, and how these can apply to your next OSHW application: 

Design Flaw: Making an error in the design can be a result of insufficient technical knowledge, failure to follow protocol/design standards, making a calculation error, using the wrong units of measure, or just an honest mistake. Now many tools have built-in error checking such as a Design Rule Checker (DRC) when you are creating printed-circuit boards (PCB). Learning to use these tools is a key first line of defense. Even better though is getting an independent peer review. For makers this can mean joining online forums and posting your schematics or pseudocode and solicit feedback. It can also mean getting friends from your local makerspace to take a look at your schematics and source code before you start breadboarding or coding. Bottom line, an independent set of eyes to take a look at your designs and concepts can save a lot of time later down the road. 

Poor Construction, Lazy Programming: Even with the greatest design, you can still run into issues while building or coding your project. When rushing to build a prototype it can be very tempting to cut corners just to get “something working.” Take your time. Build and test in modules. When it comes to software each save should be a new version so you can revert back if needed. Try to use good wiring practices such as using specific color wires for specific purpose (e.g. green is always, ground, red is always +5VDC, etc.) and cut wires to be just long enough. I could do an entire post of just good build and layout practices but I think you get the idea. 

Material Failure: Some projects can result in pretty large costs when your project’s bill of materials (BOM) contain a large quantity of components or utilizes expensive components. In that case purchasing on the cheap by sourcing components from whatever dealer you can find on the Internet may become very tempting. But sometimes you get what you pay for; counterfeit components or components with poor tolerances can cause a lot of tough to troubleshoot problems. Buying from reputable parts distributors always saves money in the long run. This goes for your tools as well, I have been burned before by using cheaper multimeters or poorly calibrated oscilloscopes. 

Operating Outside Specified Parameters: Building a device in the lab is one thing, building a device to be used in the real-word is another. Ensure you understand the operating environment clearly and spec parts that can tolerate the extremes, for example temperature or humidity. Invest in ruggedized enclosures if need be. But most importantly ensure customers understand the tolerances and the parameters whereby your device will work and the risks associated with not following that guidance. 

Lack of Imagination: This is the hard one. This is the world of “unknown unknowns” meaning that complex systems have complex interactions that can’t always be modeled with 100% accuracy. Influences of 2nd/3rd order effects of inputs at the interfaces between components can be hard to predict. Trying to anticipate all possible user interactions is highly unrealistic. There is much you can do to try and prevent bad inputs or interactions from having crippling effects on your device. Think exception handling in software or safety mechanisms in hardware. In systems engineering we perform Failure Modes, Effects and Criticality Analysis (FMECA) which is a fancy way of saying we brainstorm all possible ways our components could fail, how they will effect the overall system, and how to mitigate the impact of failure if it occurs. In my opinion the best you can do is to follow best practices similar to looking for design flaws. Get as many sets of eyes and brains to think of possible failure modes in your design and then to the best of your ability design the possible failure modes out by building in safeguards, this applies equally to hardware and software. Training end users to use a device properly also helps. 

Failure gives us the opportunity to learn from our mistakes - but perhaps more importantly, it can give us the desire to do the best we can and to push the envelope past "good enough" - and into a better tomorrow. After all that is what engineering and the maker movement is all about… just ask Neil Armstrong!

Now it’s your turn. Let us know about any engineering disasters you’ve encountered in your career or hobby. Share with us what you've learned about how to prevent that problem from occurring again, and if that failure helped you to become a better engineer or design/build a better product.