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 that 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 the hardware 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 changes 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 interest in high jacking that device and using it for their own purposes. I once put a single, prototype device I was working with on the net 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. Use more metrics than just cost!
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 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. That danger could be as simple as the thought process that a developer goes through when debugging software through putting a company out of business. 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.
