embedded software boot camp

Is it a Bug or an Error?

Wednesday, January 31st, 2018 by Michael Barr

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.”

hoppers_moth_bug

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? Comment below.

Tags: , , , , , ,

14 Responses to “Is it a Bug or an Error?”

  1. Michael Barr says:

    Fun fact: The Mark II could perform an incredible 8 additions PER SECOND! More than twice as many as the Mark I.

  2. Rod Chapman says:

    I also hate the use of “glitch” to make plain old incompetence sound like it’s OK.

    I was also trained in PSP by Watts Humphrey. PSP insists on the use of the word “defect” not “bug” or “error”.
    I strongly comment PSP’s defect tracking and measurement regime to anyone… you eventually find out what a brilliant programmer you’re not… 🙂
    – Rod

  3. Rod Chapman says:

    Sorry.. that should be “commend” not “comment”… a defect obviously…

  4. Saurabh says:

    The simple case is bug can be at any place, sometimes even in designs itself, most people love to call it bug beacuse the pain they face in first catching and then debugging it.

  5. Mike Sikalo says:

    Many people say “defect”, following RUP or ISTQB terminology.

  6. W Murray says:

    Often due to complexity there may be hundreds of errors caught in testing and more than a few test escapes — And not all errors are due to software — for example on a pair of MSP430 projects I was testing I found that the 430 had to have its voltage rails above 3.3V at all times to run at 16MHZ error free — a hard item to find in the 30+ pdf files on that one part from TI — In summary I think the complexity lowers the expectations

  7. Swapna Obulareddy says:

    Defect is another term used which is as strong as errors or mistakes.
    Cause is ‘error’ or ‘mistake’ and result is ‘defect’.

  8. Patricia Herdman says:

    Until corporate IT executives got involved and began insisting that we referred to software problems as “issues” or “incidents”, we test folk used to call them DEFECTS.

    Given that we have no software safety regulations / laws, probably time to shift from the cutesy-pie terminology so that the public gets that when their software fails, a mistake was made by a company and someone other than the driver should be held accountable.

  9. Lisa Simone says:

    I third the nomination for use of something stronger like “defect.”

    In fact, as a part of AAMI (Association for the Advancement of Medical Instrumentation), we will be publishing a standard later this year on the Classification of Defects in Health Software. Even though the title includes the word “health” it’s actually a very generic taxonomy that can be applied to any software product.

    Once we can start being honest that it’s not just a harmless little “glitch” and we have the language to describe it, perhaps we can attack the scourge software defects in a more concerted manner.

  10. Julian Day says:

    So if not a debugger, a dedefecter? a fecter? On unrealistically a perfecter? Maybe what we call a debugger is really a comprehension tool.

  11. Mal Watts says:

    Other people have already said it; there are convincing reasons for using the word ‘defect’. I’ve followed the practice of referring to the faults in software (whether or not they fail) as ‘defects’.

    I also was convinced by the arguments in PSP and related documents.

    The simple version of the argument is that “bugs” (like the insect form) sound like they will exist regardless of my personal practices; they sound kind of harmless, and by analogy to the insect kind, they have a life of their own; it’s not really anyone’s fault and it’s to be expected if they just turn up now and then. Insects (bugs) are inevitable.

    But if I use the term ‘defect’, and I consider how those defects came to get into a product, it’s clear that they were placed (injected) there by someone (maybe me), and they are not inevitable. Someone can take responsibility – me – for having injected (or missed detecting) a defect, and subsequently take responsibility for understanding how and why, for reducing the number and severity of defects created, and for improving practices to find and remove them early. The implication is that people are responsible for defects – they don’t just “happen”, like bugs. And defects sound like they can affect any artifact; requirements, design, code, data, documentation…

    Consider which phrase is more likely to attract or divert management attention : “just a couple of bugs in the software” or “a defect in this safety-critical software system” ?
    When we allow them to be called “bugs”, it feels to me like we’re implicit in an attempt to downplay their importance or potential consequences.

    So it’s “defects” for me…

    * Probably anyone working in a safety industry will know that there are multiple competing error/fault/failure models [ISO versus IEEE…], and the incompatibilities between them can be frustrating and confusing. ‘Defect’ helps to skirt around this, a little…

  12. My 2011 rant on this subject (before I retired from active software service) might be of interest to some people, as might be the comments appended to it around that time.

    https://peterbushellwp.wordpress.com/2011/08/25/whatever-happened-to-the-worst-case/

  13. Igor M. says:

    It’s more complicated than that: a specification error (external factor not foreseen), design error, and implementation error. I do have a better taxonomy somewhere but those are broad categories that a “bug” gets sieved into.

  14. Thorsten Langenhan says:

    The point is that software development is not only embedded. In application development I remember that we had as acceptance criteria not more than 1 critical fault or 5 medium faults or 40 low priority faults. Low priority fault was eg. a typo in the any kind of user interface or documentation. Medium was a fault that had a workaround with a little more effort. Critical was an absence of a function so that no workaround could help or only with massive effort.
    Yes a typo would have been a somekind of a bug, that would annoy the user but not lead to defect. Change mangement for such low priority faults could be handled on a shorter way, if it is even documented.
    So far for the big picture of software, but I fully agree that bugs are no option if you handle a software which has integrity requirements. This is not only for safety, I don’t want my bank to send my paycheck to another account.

Leave a Reply