7 cardinal sins of embedded software development

July 09, 2015 // By Jacob Beningo
Along with its best practices, every industry has its sinful ones. The cardinal sins are the sinful practices that many are aware of, but that are just too tempting or too easy to fall into. The embedded software industry has a number of these cardinal sins but there are seven in particular that seem to have pervaded the industry throughout the decades.

Sin 1 – Not tracking metrics

Failing to track development metrics may seem like a minor sin but metrics are an integral part of embedded software engineering. Metrics provide a means for not only evaluating progress and issues but also for estimation. Engineers quite often are asked, “How long will it take?” or “How much will it cost?” Questions of time and cost should be based on empirical data, not on an off-the-cuff whim that is related to how optimistic the engineer is feeling at the time. Once upon a time, prior to when I tracked metrics, estimates were either unrealistically large or idealistically small. Without basic metric tracking determining how much flash space a microcontroller needs is extremely difficult. How is an engineer supposed to know how much RAM/ROM a typical digital input/output or UART driver takes if it isn’t tracked?

Sin 2 – Hacking instead of designing

One of the sins all too often committed is mad-dash code writing with no blueprint, design, or flow charts that, through the grace of God, happens to work in the most minimalistic test cases and conditions and is then deemed worthy to ship because it is “functional." In fact, over the course of the last decade or so, the concept or idea of being a hacker or even a maker has become romanticised by society. Society has embraced this concept that the software engineer should be a rogue hacker who, with little design or forethought, can create a revolutionary and “complete” product on a very short time schedule.

The fact is, embedded software ENGINEERING is not a hack discipline. Engineering requires forethought and design in order to be truly successful. Implementation and testing should follow design and architecture. A bridge isn’t built first and designed with documentation later.


next; don't do ground-up every time...