A short time ago, I was under pressure to repaint the house while simultaneously delivering several high-priority work projects. It was impossible to do both the right way in a timely manner so I began a search to find a company that could cover the paint job for me and came across one named “Quality over Quantity”. It was a local start-up company who were more interested in providing quality service and work to a few customers rather than maximizing customers to the detriment of quality. So, what exactly does this have to do with embedded software?
I’ve noticed that a majority of companies that I encounter developing an embedded product seem to be more interested in quantity over quality. Teams are furiously hacking away at their product code adding as many features as they possibly can in impossibly short deadlines. Many companies will claim that quality is important to them, but a quick examination of their product behaviors let alone a look at their software development life cycle methodologies tell a very different picture. A company that is focused on quality embedded software will have several key ingredients that can be found in their software development life cycle processes.
First, they actually have a software development life cycle process that is not just defined but adhered to and regularly updated to meet their needs. These processes don’t have to be bullet proof, bureaucratic processes but simply defined and followed best practices.
Next, testing needs to be built into the developers’ day-to-day behaviors. Testing is not something that is done only at integration right before the product goes to market or will be demonstrated to a customer. Developers should be creating unit tests, modules tests and integration tests that can be performed on a continuous integration server. Several years ago, this was certainly something that was challenging for embedded folks, but today there are fewer and fewer excuses not to have these tools setup. (Trust me, I’ve tried to come up with as many as I can, and they just don’t hold water).
Finally, code reviews should also be a natural part of development. It has been shown countless times that the best way to remove bugs from code is to perform regular code reviews. Code reviews certainly catch issues with coding styles, missing conditionals, and so forth but I’ve found that the real power in a code review is verifying requirements and that the code does what it is supposed to do. Just talking through what they code does and how it is doing it can often reveal oversights or bring up questions about what is being done. In fact, even as an independent consultant when I write code I will either get a colleague to review my code or I’ll schedule walk through with my client.
What I’m getting at is that as embedded software developers, embedded product designers, or even executives running embedded system companies need to stop focusing on quantity and start to focus on the quality. I believe it is often a misnomer that quality software is more expensive to develop. I’ve seen time and time again that teams who focus on writing fewer quality lines of code versus a large number of lines of code seem to do so in less time and lower costs. Unfortunately, I haven’t dug through scientific literature and studies to determine if this is a fact, and it may not be that way for everyone, but for me personally and many of the teams I interact with, the statement seems to hold true.
So, are you, your team or company focusing on bringing quality products to your customers or are you simply doing as much as possible in the shortest time possible? If it is the later, what are you going to start doing to get your software development under control?
