Is it a Bug or an Error?
Probably you’ve heard the story of how Adm. Grace Hopper attached a moth that was dislodged from a relay in the Harvard Mark II mainframe to an engineering notebook and labeled it the “First actual case of bug being found.”
Designers of electronics, including Thomas Edison, had been using the term bug for decades. But it was mostly after this amusing 1947 event hat the use of words like “bugs” and “debugging” took off in the emerging software realm.
So why is it that if a bridge collapses we say it was a failure of the design and not attributable to a mere “bug”? As if it were an external force or an act of god that caused the failure? Why do only software engineers get this linguistic pass when failures are caused by their mistakes the same as other types of engineers?
Failures of software are commonplace everyday events. Yet such failures are not typically the result of a moth or other “actual bug”. Each such failure is instead caused by human error: some mistake has been made either in the requirements or in the implementation and these human mistake then have real world consequences, including sometimes compromising the safety and security of product users.
Should we, as a community of professionals, stop using the word “bug” and instead replace it with some other more honest term such as “error” or “mistake”? Might this help to raise the seriousness with which we approach our work and thereby the safety of the users of our product?
What do you think? Please comment below.
- Comments
- Write a Comment Select to add a comment
I would say that the word "bug" is now too ingrained in both the software profession and in popular culture, BUT it is too informal and we should do better.
Even now as I type this response, on the right-side of this editor, I see two books by one Michael Barr, where each book has rather nasty looking bugs on the cover page! Is that ironic? :-)
In my own terminology I tend to use the word "Case" when referring to a defect or bug. But will still frequently use the word bug without realizing it. Additionally, I use the phrase "design flaw" or "design error" when referring to larger issues.
Examples:
- 'Case' aka 'bug' aka 'mistake' aka Problem Report , etc
- buffer overflow
- copy/paste induced bugs
- floating point issues
- forgot a mutex lock/unlock
- forgot to check for nullptr
- Design Flaw or Design Error
- underpowered microcontroller selected without consideration of overall requirements
- lack of software design resulting in spaghetti code
- used a traditional main loop design when the requirements were better suited to RTOS or event driven design
- Used C instead of C++11 or newer (ha ha)
- frequent heap usage in a system intended to run 24/7
- Using a RTOS when a simple and reliable main loop design was appropriate
So yes, I believe the term "bugs" is an informal term and should be avoided. Especially if engineer is in your title! :-)
Matthew
Maintenance [fixing bugs]/enhancements accounts for about 80% of software costs, we read and hear.
C/assembler is notorious buggy technology. we read and hear.
Virtual machine technology about order of magnitude more reliable, we experience.
Didn't see Forth listed in
Comparison of real-time operating systems
https://en.wikipedia.org/wiki/Comparison_of_real-t...
:(
Bug is an informal term used, which is nothing but an error or an anomaly in the expected outcome for a given input, or un-expected behavior of the product.
Many Industries use different term like "PAR", (product anomaly report), and some industry use the term "Bug" as it is. The term debug, debugger has come from "Bug" only, and as time passes this will become a formal term itself.
Already in IT industry and embedded industry the term "Bug", "Debug", "Debugger", "Debugging" has already deep rooted and I feel it can be used as it is.
I feel it as a synonym to "error" or "anomaly" or "fault" etc.
My brain space typically wants the full context in which “bug” and “error” are used to determine the severity of the topic/issue being addressed. I typically think an “error” would imply the system is undergoing a non-recoverable issue; that is, something where a user might have to intervene in some capacity – reboot, recycle power, etc. – when a system enters/exits a specific state. However, a “bug” might be self-recoverable, or might not even cause an immediate problem, given a specific system state. A “bug” could simply be code mishandling a state’s condition, such as showing potential to be a latent failure through rigorous testing. I suppose, technically speaking, a design flaw covers both. To me, a “design flaw” would be how a manager would explain things to a stake holder during an update. Whereas, “bug” and “error” are looser terms and depend on the speaker and context of the problem. I agree, this is an interesting case of semantics and ultimately (for me) it boils down to their use in full context. Conversation is key!
To post reply to a comment, click on the 'reply' button attached to each comment. To post a new comment (not a reply to a comment) check out the 'Write a Comment' tab at the top of the comments.
Please login (on the right) if you already have an account on this platform.
Otherwise, please use this form to register (free) an join one of the largest online community for Electrical/Embedded/DSP/FPGA/ML engineers:
