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
Hi Jacob,
Appreciate your blog entries. Unfortunately you are bitten too, with the name of your next webinar: “Designing and Debugging RTOS based IoT Applications”. Maybe you should start correcting it.
Regards
Thanks for the comment. The webinar title is set using the debugging phrasing and will be commenting about during the webinar. Unfortunately the promotion for this webinar started before the conversation to try and squash bugs for good.
To you and perhaps some other native English speakers, the term bug may indeed have a connotation related to its colloquial meaning. But the vast majority of those involved in software development, are not native English speakers. To them, I think it simply means “a problem that needs fixing.”
your reference number 2 has a bug or error or is it a defect?
I would prefer ‘defect’. But whatever you name it, first you have to find the cause, and maybe it was a bug …