The Top 5 Dangerous Assumptions Embedded Software Engineers Make

Whether we like it or not, we all make assumptions that form the foundation on how we think about and design embedded systems.

Whether we like it or not, we all make assumptions that form the foundation on how we think about and design embedded systems. In many cases, the assumptions we make are trivial and will have a minor impact on the systems we design or the companies we work for. Sometimes though, the assumptions that we make can be dangerous and affect whether our product or even our company will be successful. Let’s examine five dangerous assumptions that I often see teams in the embedded systems industry make.

Assumption #1 – The Hardware Works Perfectly

It’s not uncommon for a software engineer to be suspicious of prototype hardware that they are starting their software development on. We all know that hardware, just like software, goes through several iterations until it works as the design engineer intended it to. Once the hardware gets to a solid revision though, we often assume that we won’t have any problems with it, which is a dangerous assumption. Even perfectly designed hardware can still experience latch-ups, single event upsets, and other potential issues. The odds of seeing these issues during development in a few dozen prototypes under controlled conditions is minimal but once thousands or maybe even hundreds of thousands of devices start to be deployed around the world in various environments, the chances are much higher that the system will experience these issues. The question then comes down to whether the system and software is designed to recover or handle such events.

Assumption #2 – No One Is Interested in Hacking My Device

I often run into companies both small and large where the thought process on security goes something like this:

     • Who would be interested in hacking our device?

     • Surely our device is not that interesting to anyone.

     • I can’t imagine anyone would want to hack our device. We are just a small fish in a very big    pond.

     • Do we really need to spend time on security?

     • Security can be time consuming and expensive!

     • Let’s just try security through obfuscation and hope that is enough.

The fact is, no matter how insignificant a team may feel their device is, someone will be interested in hijacking that device and using it for their own purposes. I once put a single prototype device I was working with on the internet so that I could remotely access it over a weekend. I thought a few days over a weekend would be no big deal. To my surprise, the device didn’t make it two days before someone had found it, hacked it, and modified its behavior for their own purposes.

Assumption #3 – Open Source Software Will Decrease Project Costs

Open source software is truly a gift and a curse. You can’t beat the price of free software. The danger with using open source software, specifically when we are considering software designed to run on a microcontroller, is that developers assume the software has been:

     • Tested

     • Secured

     • Meets their purposes

     • Has been integrated with other software they are using

     • Is defect free

     • Follows industry best practices

and the list can go on and on. I don’t want to scare the reader away from using open source software, but I do want the reader to carefully consider when open source software is appropriate. To think through actual savings versus the actual costs. Costs? The software is free! Is it really, though? Many developers overlook the cost of:

     • Integration

     • Technical support

     • Debugging

     • Quality improvement

These assumptions are dangerous because they can affect project timing and costs significantly. I’ve seen many times when a company made the decision to go with a software package because it was open source and free only to have it cost them dearly in project costs and time to market.

Assumption #4 – It’s Just a Bug in the Code

I’ve become convinced that just thinking about defects in our software as bugs puts a psychological spin on bugs that makes some people believe engineers are not responsible for the results our software produces. We assume, it’s just a bug, a minor inconvenience, I’ll make a change and recompile and see if it goes away. If it doesn’t, I’ll just repeat until it is. A bug though can be an error. It’s a mistake, as uncomfortable as it sounds, and the engineer should take responsibility for that mistake and try to minimize their occurrence in the future. Instead, we wave it off as just being a bug and go back to coding, spending on average 40% of our time removing them from our projects. That is dangerous and undoubtedly not just costing teams untold amounts of money each year, but causing some companies to fail.

Assumption #5 – We Don’t Have Time For …

Testing. Training. Metric Tracking. To do it the right way the first time. Pick your favorite one or the one that hits closest to home. Nearly every embedded development team I encounter doesn’t have enough time for something. They make the excuse that we don’t have time to fully test our product. Quality must not be a priority then. There isn’t enough time to train and learn new techniques. Leveraging new techniques and technologies to decrease development time and costs must not be a priority. I’ve become convinced that if there isn’t enough time for us to develop our products, then we must be focusing our efforts on the wrong things. Shouldn’t testing throughout the development cycle decrease debugging time? Shouldn’t learning new techniques decrease the time it takes to do things which gives us more time?

We are often too busy putting out fires and rushing to get things done rather than asking the simple question: “What needs to be prioritized in order to get this job done faster?” I’ll give you a hint, it’s rarely doing the work faster.

Conclusions

Each assumption that we’ve looked at in this article has the potential to be dangerous. I would encourage you to think through these assumptions and ones not listed and determine if the assumptions that you are making could affect the success of the project that you are working on or even the success of the company. 

Jacob Beningo is an embedded software consultant who currently works with clients in more than a dozen countries to dramatically transform their businesses by improving product quality, cost and time to market. He has published more than 200 articles on embedded software development techniques, is a sought-after speaker and technical trainer and holds three degrees which include a Masters of Engineering from the University of Michigan. Feel free to contact him at [email protected], at his website www.beningo.com/, and sign-up for his monthly Embedded Bytes Newsletter.

ESC, Embedded Systems ConferenceJoin Jacob Beningo at ESC Boston!
Join Jacob Beningo for three can't-miss sessions at ESC Boston, April 18-19, 2018. He will be on-hand live at the Boston Convention and ExhibitionCenter, where he will be discussing: "Transitioning Embedded Software From C to C++," "Jump Starting Code Development to Minimize Software Bugs," and "Verifying and Debugging Real-Time Systems Using Deep Insight Analysis."

Comments (4)

Please log in or to post comments.
  • Oldest First
  • Newest First
Loading Comments...