Why quality is critical for embedded software
Quality is at the heart of everything we do at Bluefruit. It is key factor in all of our work, from ensuring that the software we write for medical devices meet international standards to the time we’ve invested in developing a deep understanding of microcontrollers or working with brushless motors. Whether it’s a traditional embedded software project or working within the Internet of Things (IoT), quality permeates through our projects and our working practices.
Here’s what our team had to say in a recent video about what quality means to them:
Not convinced quality is the most important thing? Have a quick think about the expectations you have for the objects around you. You expect that your TV will still work after an upgrade, that the electronics within your car will function safely and that your pacemaker won’t be hacked. Software quality isn’t just something desirable, for product owners (and their customers) it should be a must have.
What do we mean by high quality software?
We understand that quality can mean a lot of things to different people and it’s a term that is often over used or misappropriated. As software engineers we define quality as a combination of providing a reliable and enjoyable experience for the end user and code that is robust while also adaptable for continuous improvement and evolution. We’ve gone into great detail previously around the importance of perceived and conceptual integrity, but if you don’t have time to read that at the moment, the summary is “you need to nurture the roots to get good fruit”.
Putting quality first
How does a quality focused project differ from a more traditional approach. To start with let’s take a look at this “Iron Triangle” diagram. This is used to demonstrate that the focus of a project is usually placed on the scope (specification of features), and that as a result, budget and timescales are often compromised.
At Bluefruit we add quality as a fourth element to show how focusing on the scope will affect that as well.
As you can see, putting the scope as the primary driver for the project, you might end up with something that fits the original scope, but the quality may suffer as a result. As we illustrated earlier, within the embedded software and IoT space where we work, compromised quality can result in increased costs fixing errors, additional time improving the product and ultimately a negative impact on your reputation with clients.
To put quality first we apply Lean-Agile methodologies and flip the modified Iron Triangle so that quality is the fixed metric with scope, timescale and budget becoming the adjustable elements.
While, this may seem like an idealistic approach, we’ve found that by focusing on quality first we are able to often improve the over all timescale and budget of a project. Both in the velocity we are able to achieve during development and ultimately because or a reduction in costs fixing major software issues later in the development lifecycle.
In the next post we will be talking about how we achieve quality in our projects (spoiler: testing, testing, and more testing).
Did you know that we have a monthly newsletter?
If you’d like insights into software development, Lean-Agile practices, advances in technology and more to your inbox once a month—sign up today!
Find out more