We're hiring!

We're actively seeking designers and developers for all three of our locations.

It’s Not an Issue. It’s a Bug.

When something goes wrong, do you or do you not say something like this:

My bug crashed the system. Our bug crashed the system. Some bug crashed the system. There’s a defect. We don’t know how to use it.

Or do you tell your client that you’re “having an issue”?

A bug.

There is no issue here! The feature is broken! There’s no need for discussion, understanding, and compromise here. The feature is broken.

Let’s work together to stop deferring blame and start accepting responsibility!

I often wonder how the word issue (as a noun) began replacing bug or problem in developers’ vernacular. Outside of development, I generally hear the word applied to fuzzy political or economic topics. It implies, “There’s no right answer, compromise must be found, and debate and discussion will bring us to compromise.”

Development might be more fun if every problem we ran into was worth a hearty debate and discussion, but in reality, problems are usually a bug. Or the person using a library isn’t using it the way it’s meant to be used. We write a failing test, fix the bug, and move along.

Perhaps the word came into use because it comes across as a bit softer than the word bug. “We fixed an issue with the Apache web server,” sounds a lot better than, “We were using the Apache web server incorrectly, and the application was crashing.” It’s a subtle way of deflecting responsibility onto another party.

Upon further thought, this behavior comes across as fairly petty, doesn’t it? That must be it. It isn’t the overuse of the word or the dilution of the definition that bugs me, but the deflection of responsibility. Indeed, how petty.

I’m thus going to add the word issue to the list of weak language. I’m removing from my vocabulary. Other words and phrases include like, kind of, sort of, and I guess.

Why don’t you add issue to your list as well? Let’s use more accurate words instead and take back responsibility for our actions and mistakes.

Edit 7/17/2012: inserted a missing word in the introduction

Matt Fletcher (76 Posts)

Matt is a software practitioner with Atomic Object.

This entry was posted in Development Practices and tagged , . Bookmark the permalink. Both comments and trackbacks are currently closed.

5 Comments

  1. Phil Kirkham
    Posted July 17, 2012 at 11:23 am

    So what do you think of deficiency, anomaly, problem or Software Performance Report ?
    :)
    Cem Kaner does advise not calling them defects as that can lead to legal problems – this thread on the STC shows how many names are used in the industry ( and also gives Michael Boltons definitions of bug and issue )

    Taking responsibility is a great attitude but then you have to devote time and money to fixing them – which could be why some places like to call them issues then they can argue about who pays for it to be fixed ( speaking from painful experience of too many conference calls where there were aguments about whether it was a bug or not )

  2. Posted July 17, 2012 at 1:46 pm

    I remember a time where a “Bug” was a coding error, and an “Issue” was an analysis error. And because management made the mistake of using metrics for performance evaluation, what was a bug and what was an issue became highly politicised.

    Matters came to a head when I get an angry email in 14-point red bold from a developer because I’d raised a bug that he thought was an issue. Didn’t matter that regardless of whether it was an issue or a bug, the feature didn’t work, and would have to be fixed anyway…

  3. Posted July 17, 2012 at 1:55 pm

    Blame is a terrible thing and just leads to people avoiding responsibility wherever possible. I do wish people weren’t so precious about the labels we assign to these things (“bug” does seem quite benign to me) but people will be people…

    We use “Quality” Centre at work and I despise it as a tool. That uses the term “defect”

  4. wpkf
    Posted September 26, 2012 at 11:39 pm

    Taking responsibility is good direction but as someone mentioned, we, programmers, developed according to the ‘wrong requirement’ and end-user is not happen. It is not our fault also we are responsible to ‘fix the issue’.

    • wpkf
      Posted September 26, 2012 at 11:39 pm

      ‘end-user is not HAPPY’.