Bugs vs. Defects, Reprise

Well, all the comments on my No More Bugs post got me thinking. To answer a few comments here and elsewhere,

  • I’m not trying to blame developers for being human and making mistakes. When I was a developer, most of my mistakes involved code. As a manager, most of my mistakes were in my dealings with people. Fixing code is much easier than fixing relationships.
  • I’m not trying to play word games. To me, the intention of bug vs. defect is different.
  • I’m willing to admit I’m alone in this thinking :-), or at least, I don’t have much company (yet).

My intention with naming mistakes as defects is something I said in an earlier article:

It wasn’t just that I wanted the project team to be aware of defects, I wanted them to be comfortable with acknowledging defects. They had to realize that they had produced defects and that they would not necessarily be able to fix all of them for a given release. That, in turn, makes awareness of defects less overwhelming. It makes the defects bearable.

I hope this post and the other one has started you thinking about how we create problems and we prevent them. Your comments have helped me think more. Thank you.

12 Replies to “Bugs vs. Defects, Reprise”

  1. You’re not alone, Johanna! I’ve been using this distinction for a long time, and frankly my teams have never thought it was just about word games. I agree completely with your sentiments here.
    Btw, I think it was Gerald Weinberg who first made the distinction clear (to me at least).

  2. No, you’re not alone. I’ve been trying to use the term “defects” since I was a TD at EA in 93 – 94. I enjoyed the entry, I just don’t write a lot of comments.
    As you suggest, I think organizations like the term “bug” because it has a connotation of cuteness and of self-determination. “Defect”, on the other hand, sounds like something _bad_, and it sounds like something _you did_ instead of something that just happened.
    I’m supportive of the idea of keeping track of where defects enter the system. Unfortunately, that information would eventually get used to evaluate programmers (and designers) and would thus be “gamed”. I just want to know where the defects are inserted into the program so that I can figure out how to keep it from happening.

  3. Tom DeMarco has a page or two in his book “Controlling Software Projects” (1982), specifically explaining why “defect” is a better word to him than “bug”. Look at the start of chapter 19.
    The best line out of his little screed is “I believe that if we stopped assuring ourselves that bugs were allowed, there would be fewer of them.” Then, he goes on to say explain his rationale for using the term “defect” instead of “bug”, and only discusses software quality in terms of defects.

  4. Gerry Weinberg gives the same advice and for the same reasons in his excellent series of books “Quality Software Management”. I recommend they should be read by anyone interested in software, or management, or quality.

  5. I’m with you on bugs vs. defects. While defects are introduced by people (we all make mistakes), they are allowed to remain by process. Only through a good development and review process will defects be discovered and removed.

  6. I will join in on saying that you aren’t alone in this line of thinking. I think it’s too easy for people to assign “bugs” to the same category as “criticism”, which many people don’t deal with very easily.
    I’ve been thinking about defects (or more generally “issues”) a lot in the context of project trying to integrate the planning and addressing of defects into cycles of planned work. I like this because it identifies a defect as exactly what it is, a work task required to enhance or change the behavior of a system. In many ways a defect is just a task as you would find in a new feature or enhancement.

  7. Your statement “They had to realize that they had produced defects and that they would not necessarily be able to fix all of them for a given release.” interested me.
    Usually I work hard to convince the DEVELOPMENT team that they should strive for there to be *NO* bugs (or defects), while simultaneously trying to convince the business owners that they’re never going to get rid of ALL the bugs, and they should put some off for the next release.

  8. I too have been trying to encourage the use of “defect” rather than “bug.” One idea that really caught my attention from some source I have, regrettably, forgotten, was that of a Japanese company during the 1980s that referred to software defects as “spoilage.” It makes sense to me, given that what we have to spend as developers is time, and when we spend it making defective software, that effort is “spoiled,” wasted, and fundamentally unrecoverable except to the extent we learn from it.

  9. I’d suggest a distinction between defect and minor problem (incident, issue). Defects are very bad. My car blows up when you start it. That’s defective. My car idles a bit higher than I’d like. Just an issue. Bug covers the whole range, thus equating BSOD with “takes too long to…”

  10. Sometimes bugs aren’t defects. The term bug has a broad interpretation and therefore is a better general word for problems in software
    Statement:
    It is a DEFECT that the software doesn’t print this line in green.
    Answer:
    It’s not a DEFECT, it was never a requirement.
    vs
    Statement:
    I put in a BUG to have this line printed in green because it looks prettier.
    Answer:
    Ok, we can make that change.
    Well, you say, we could use an issue database and a defect database and maybe for good measure throw in another wishlist database and what have we done? We’ve made it 2-3 times as hard to get one unified report of what needs to get done before a piece of software is ready to be delivered. Calling everything a defect is like calling all soft drinks a Coke, you get the general idea, but you still have to ask “what kind of Coke do you want?”
    Bug is vague as well, but it does not carry the implication that someone screwed up, that someone didn’t do their job. When in actuallity a lot of times you have people that don’t know how to use the software getting undesired results and calling things a defect. This software is “broken” when the real problem is they just don’t know what they are doing. (Quite frankly a lot of these issues are a defective UI, which is not even reported, because the focus is on the action that didn’t happen as expected, but I digress)
    And part of the original complaint against bug was that the bug might get marked invalid. Well, how do you think that person will feel when their defect gets marked as invalid?
    If you want to thave different flavors of bugs, defect is certainly one of those flavors, but to lump new feature requests as defects carries an overtone I don’t want to bring into groups that I lead or code in.

Leave a Reply