We usually think the word "bug" appeared in computer science inside of a report sent by the engineer Grace Hopper, after having spotted a failure due to a moth stuck in an electrical relay of the Mark II.
Grace Hopper is a huge name in the computer science history: COBOL creator and lead developer of the Harvard Mark I, II and III.
Solely, there are two things we should not put aside from this word history :
The bug in question was not discovered by Grace Hopper herself, but by the operators working on the machine, the latter only wrote about the incident in an officiel report, which let a permanent mark in our history.
But something even more surprising, the word "bug" didn't even came up with the computer science. This word was already in use in the engineering field before, so much that we got traces of it by Thomas Edison about his inventions and by Isaac Asimov about his fictional robots.
Nonetheless since it first appeared, the usage of this small word never was so frequent, often hiding too many meaning to a simple three-letters word.
The hidden meanings
When working on a programming project, it is very usual for a developer to receive bugs notices from very different causes:
- "The text color is wrong"
- "The button doesn't appear"
- "All data got erased"
- "The app suddenly stopped working"
All these feedbacks are due to "mistakes" made by the programming team (or the project team in general), and these errors can have little consequences (or not) on the final product.
It is only a mistake if the result is different from the specifications, otherwise the specs need to be updated.
Let's explore some alternative (and more precise) words we could use to describe a "bug", depending on the gravity of the situation it induces:
A defect designates a simple divergence per specs and according to the result expected by the client. We can talk about a graphical defect, a writing defect, a feature defect, etc...
Any error implying a different state than the expected state is a defect, but if this mistake only causes a simple defect, then consequences are often acceptable, and some of them can be put aside if they are not priority.
A wrong color or a typo in a text is a simple defect.
An anomaly means the error, or mistake, induces a malfunctionning software, it is not the "normal" state of it anymore. That also means that it's not only influencing the user's feeling when navigating the software (like a simple graphical defect could do it), but it's impacting the use of it.
An anomaly doesn't make the software unusable, it only induces a wrong behaviour according to the specifications, which can be problematic.
If during the signup, the user receives an e-mail about deleting its account, this is an anomaly ; the software can still be used, but the behaviour induces an unexpected event.
A failure is the most critical level a programming mistake can provoke. It implies the software, or a part of it, is unusable, or that its behavior is so far from what's expected that it becomes useless.
A failure must be dealt with as soon as possible and cannot be postponed as the whole functional side of the product is at stake.
A crash when launching the app is a typical example of a failure.
The term "bug" is way too generic and does not carry enough meaning about the priority of an issue inside a software.
Instead we will prefer using the words defect (divergence according to the specs), anomaly (not working properly) or failure (software or feature unusable).
I hope this post was useful to you, see you soon on the blog !
About the author
Hi, I am Nicolas Brondin-Bernard, freelance web engineer since 2015 with a passion for sharing knownledge and experiences.
I'm also a coach for junior web developers, you can message me on email@example.com, on my website or follow me on social networks like Twitter to avoid missing the bests posts or my future projects!