7 cardinal sins of embedded software development
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 blue print, 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 romanticized 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.
Sin #3 – Starting from scratch
Digging down into the deepest level of hardware and twiddling bits to make something happen in the real world through software is fun and exciting. Embedded software engineers want to develop everything related to the software, starting at the lowest levels and working up through application code. It is the first instinct, and often the insistence, of developers that the design be done from scratch.
The problem with doing everything and starting from scratch is that it is time consuming and costly. Embedded systems have become too complex, development times too short, for the average project to start with a clean slate. Vendor code, 3rd-party components, open source, and other standards should be leveraged to get the job done. Why spin your own RTOS when there are so many commercially available and tested alternatives?
Sin #4 – Improper tools for the job
Imagine for a moment a plumber coming to fix pipes in your home. The plumber shows up, provides an hourly rate of $100 per hour, and upon agreement returns to his truck to get his tools. When the plumber returns he pulls out his sledgehammer and needle-nose pliers to do the repair work. Confused and concerned you ask, “Where is your pipe wrench?” The plumber responds, “My request for a pipe wrench was denied. It’s OK. I’ll eventually get you squared away.”
Strangely enough a situation quite similar to this plumber is happening everyday all over the world when software engineers request software tools to do their jobs. Basic items such as a lint tool are being denied because they cost a few thousand dollars. A simple look at the ROI on a software tool compared to the yearly cost for the engineer should show that software tools allow things to be done faster and at a higher quality, making these tools a worthy investment. Yet many engineers tell me they can’t get approval to purchase even the most basic ones. Interested in a professional compiler with support tools to debug faster and generate more efficient compiled code for $1000? Better luck next year; a new $15,000 scope was just purchased for the intern.
Sin #5 – Lack of continuing education
The number of transistors in a processor roughly doubles every two years. As a result, the capabilities and technologies that embedded software engineers must use and develop also literally change at an exponential rate. Yet despite these rapid changes in the industry, many companies do not plan for or encourage their engineers to attend conferences or training.
Part of the lack of continuing education seems to be due to design cycle timelines and pressures; there is too much to do and a company can’t spare their engineers or the cost for them to be out of pocket for a few days. But the question companies should really be asking is whether they can afford to have engineers without the latest development techniques and knowledge.
Sin #6 – Working too many hours
When a deadline is looming and additional bodies can’t be thrown at a problem, what happens? Engineers work overtime. Working too many hours is a common problem amongst embedded software engineers. Firmware runs the world and right now there just aren’t enough firmware engineers to bring to life all the devices that society demands be built. Even worse, the rate at which society wants those devices is on ever decreasing timelines. There is always a rush of needing the software done yesterday.
But working too many hours though is a sure way to burn out. Rather than speeding up delivery, chronic overtime will only delay delivery. Don’t fall into the continuous over-time trap. A fresh mind can work far faster and efficiently than one that is tired and burnt out.
Sin #7 – Failing to follow best practices
MISRA-C, CERT-C, and a number of other industry standards contain the knowledge and wisdom of numerous embedded software engineers. These are seasoned engineers who have been there, done that, and learned from not only their own mistakes but also those of others. Yet there are many developers who, either due to time constraints, deadline pressures, or other impediments, ignore the best practices for embedded software contained in these documents. I find it fascinating how these standards are often ignored even though they are so easily enforceable using software tools.
Cardinal sins pervade every industry. Best practices are usually designed to help prevent these sins or to at least encourage more proper behavior. But when deadlines are looming and the pressure is on, the temptation to fall into these seven cardinal sins can be nearly irresistible, and every engineer and company has at some point fallen prey to them. The real concern is how often and what one does to get back on track.
What sins have you seen pervading the embedded software industry?
Jacob Beningo is a Certified Software Development Professional (CSDP) whose expertise is in embedded software. He works with companies to decrease costs and time to market while maintaining a quality and robust product. Feel free to contact him at firstname.lastname@example.org, at his website www.beningo.com, and sign-up for his monthly Embedded Bytes Newsletter here.
Join over 2,000 technical professionals and embedded systems hardware, software, and firmware developers at ESC Silicon Valley July 20-22, 2015 and learn about the latest techniques and tips for reducing time, cost, and complexity in the embedded development process.
Passes for the ESC Silicon Valley 2015 Technical Conference are available at the conference’s official site with discounted advance pricing until July 17, 2015. The Embedded Systems Conference and EDN are owned by UBM Canon.