The very terminology that we use when developing embedded software can set our perspective and have potentially devastating effects on our ability to deliver successfully. The most commonly used term to describe an issue with software is that “there is a bug” or that the code is “buggy”. The term bug implies that there is some external entity that is fighting against us and preventing us from being successful. When things go wrong, responsibility is displaced from the engineer, who should be in control of the situation, to a phantom force and the engineer is simply going along for the ride.
Developers, teams and companies involved in software development and supporting toolchains need to start shifting their perspectives and mindsets away from bugs and instead, start using terminology that places the responsibility where it belongs, on themselves. Now I know that this sounds uncomfortable. Embedded systems are becoming extremely complex and at times the systems themselves can feel like they are alive and fighting against a developer. These issues can be caused by something as simple as not taking the time to properly decompose a complex problem into far simpler ones.
At the end of the day, what we currently call bugs are really errors or defects in the software so why not just call them what they truly are? A defect is a functional attribute or feature that fails to meet one of the desired specifications (1). An error is a mistake or the state of being wrong (2). An error could also be considered a discrepancy in the execution of a program (3).
When considering which terminology makes the most sense for developers, I personally gravitate towards defects. It’s not as harsh as saying that it’s an error which can get management or non-technical folks all worked up, but it does put the responsibility in the right place. A defect in this sense could be an unintended consequence or an unexpected result in the application. The defect doesn’t have a mind of its own and could have resulted from many sources such as:
- Improper requirements specification
- Misunderstanding hardware
- Complex system interactions
- Integration issues
- Programmer error (blasphemy!)
When I lecture on defect management (formerly known as debugging), I often would ask the audience how much time they spend on average in their development cycle debugging. The greatest responses are usually around 40 – 50% of the development cycle but I always have outliers at 80%! Being able to successfully deliver code requires developers to have the correct mindset and the belief that there are bugs opposing our every line of code leads to loosely developed software that is high in defects.
Isn’t it time that we squash the bugs once and for all and start using terminology that is not just accurate but shifts our perspectives aware from software victims and puts the responsibility and control back on the developer?
References
