Proto-Microspeak: Bug-hugging

Bug-hugging is the phenomenon of programmers keeping bugs assigned to themselves without actually doing anything to fix them. You typically engage in bug-hugging when there is a bug that you feel strongly should be fixed, but which you also simply haven't gotten around to working on yet. Meanwhile the bug sits and collects dust. You resist allowing the bug to be postponed to the next release because, "We really ought to fix this," and you also resist allowing the bug to be reassigned to another programmer on the team because "Only I know what needs to be done to fix this."

On the other hand, you are so busy with other things that you never manage to get around to fixing that bug, or because the fix is actually quite complicated and you haven't been able to come up with a big enough stretch of available time to devote to fixing it properly. In some cases, the bug is actually a enormous amount of work, and you don't really want to fix it, but you also can't bear to part with it.

Think of it as the software version of hoarding. You know in your head that you can't fix it, but in your heart you can't bear to let it go. To put it in the vernacular, you have to piss or get off the pot.

The behavior is good-intentioned but ultimately harmful to a project shipping on time because it prevents project management from truly understanding how close the project is to being finished, and your affection for the bug prevents them from reassigning it to somebody who has room on his plate to fix it.

The kicker is that these bugs that are so fiercely held like a security blanket are often ones with relatively low impact, or even feature requests disguised as bugs. "When I do X, then Y, then Z, it would be nice if there was an option to Q directly from the dialog box." Well yeah, it would be nice, but it's not in the product specification, and we have no research data to indicate that adding the Q option to the dialog box won't create confusion or there is a significant body of users who want a Q option on that dialog box in the first place.

Here is a citation:

We have a considerable bug backlog here, and it looks like we're about a week behind, but I suspect there's a lot of bug-hugging hiding in these numbers. We plan on working with programmers over the next week to get these numbers to be more realistic.

The term was coined by a manager here at Microsoft only recently, so it's not really Microspeak yet because it hasn't demonstrated any staying power. I'll file it under Proto-Microspeak.

Comments (18)
  1. Peter da Silva says:

    Sounds like you need to change the bug tracking system so that anyone can work on any bug that hasn't got any active checkouts against it. You'll still get a few people checking code out and sitting on that, but that's sufficiently obviously antisocial that it'll reduce the problem.

  2. Joe Dietz says:

    What sort of pitiful source control system would allow such anti-social behavior to be anti-social?  

    Anyways around here, I lump such behavior in with "Cookie Licking".

  3. Brian says:

    We've done well with a "zero bug" policy around here.  If you have bugs assigned to you, you're not allowed to work on any new feature until your bug count goes to zero.

  4. Pierre B. says:

    Brian: so, whenever a new cool feature is coming up for grab, you can simply assign bugs to anyone who might want to implement the feature so that you;re the only free? You can even keep a herd of sumarine low-impact bugs that you know of but haven't yet entered in the bug tracking system for just such purpose. Any system can be subverted. :)

  5. Josh says:

    @Brian: That system might work where all bugs are accurate and detailed, with reliable repros. If the bug is vague, or the repro conditions are unknown and the occurrence rate is very low, stabbing blindly in the dark is not exactly going to help matters. You may as well work on features rather than banging your head against a wall. And of course, fixing really minor complicated bugs (say, a userland crash on application exit that occurs on less than 0.1% of exits and has no lasting effects) won't improve perception of your product as much as a good new feature. Zero bug policies sound nice in theory, but they're impractical in most real world scenarios (exceptions made for certain types of embedded software designed to rigorous standards with minimal user interaction, e.g. air traffic control software).

  6. blah says:

    Those who can't do, manage.

    Those who can't manage, are top-level executives.

  7. steveg says:

    Bug hugging in a small team can be essential. Especially when your team mate(s) should be regular contributors to

    @Pierre: TANSTAFL, but sometimes you can get discounts.

  8. 640k says:

    Bug hugging becomes prevalent when management is incompetent. If the boss is a technical coach instead of a traditional slave whipper, and the team is cleansed from jackasses, then the team members gets confident enough to openly discuss any bug with the boss & other team members. When team members are punished for bugs, then there will always be lot of bug hugging.

  9. prunoki says:

    No bug hugging here. We routinely list the bugs according to their age and eliminate these. (Reassign, cancel, whatever…) But it is a nice expression.

  10. Scott says:

    I'm going to have to use this term. Having a term alters people's thinking of a problem sometimes.

    At my current workplace, this effect is caused by management. We have a lot of enhancement requests disguised as bugs, internal bugs that don't effect the customer and bugs from very old versions. The programmers would like to fix or close them all, but many of them are never closed or assigned to a release from a fear of offending the person who raised it, or offending the project manager running a specific release. It's quite frustrating having a backlog that you're officially ignoring.

  11. Bruce says:

    What's abug?

  12. Joren says:

    Wouldn't bug-hogging make more sense as a term? It uses two words in their existing meanings, instead of adding a new meaning to 'hugging'. Therefore I vote you start spreading 'bug-hogging' while the current term hasn't been ingrained yet. ;-)

    ["Hogging" implies that you are amassing bugs for the thrill of collecting them and denying them to others. The issue here is more that you can't bear to let the bug go because you love it too much. -Raymond]
  13. Johan says:

    Shades of yesteryear.  This is really just a perversion of a not so recent song by the group called Tickle Tune Typhoon that was title "The Hug Bug".

  14. Johan says:

    Shades of yesteryear.  This is really just a perversion of a not so recent song by the group called Tickle Tune Typhoon that was titled "The Hug Bug".

  15. Worf says:

    I suppose the viewpoint on the bug hugger's side is that those bugs now have sentimental value…

  16. Andrew says:

    It's only worse when the person whose name is assigned to the bug doesn't work for the company anymore.

    This is where it's up to the managers to be more on top of their bug lists. The malaise that grows when devs see an ever-growing assigned bug count when there is no way to turn the tide probably contributes to employee departure.

  17. lol@fools says:

    ["Hogging" implies that you are amassing bugs for the thrill of collecting them and denying them to others. The issue here is more that you can't bear to let the bug go because you love it too much. -Raymond]

    No, that would be bug hoarding.

    ["Bug hoarding" would have worked but it doesn't rhyme. I bet your speeches are really boring. -Raymond]
  18. Larry Hosken says:

    I find "bug-hugging" difficult to pronounce.  This seems like a term which might arise in email, but not migrate easily to spoken form.

    As a professional technical writer, I strongly suggest that you use "bug-clutching" instead.  This means the same thing, but rolls off the tongue more easily. Strongly, strongly suggest. Yep.

Comments are closed.

Skip to main content