When is a bug not a bug?

computer-bugI used to work with someone who said that most bugs in software didn’t exist.

His reckoning was down to the fact that most specifications for functionality aren’t tight enough. For example, if the spec for an adding function was to add two numbers together, adding 5 and 9 together and returning a value of 162 was acceptable. Even returning nothing, or null, or a gazillion was also ok. The specification should have said that the function had to add two numbers and return the correct mathematical result.

For a developer, this is great news. You don’t have bugs anymore, you have “undocumented features”. Feature specifications get better and it’s easier to write code that satisfies the requirements.

It’s a bug!

But I personally think blaming bugs, and they are bugs, on the specification writers is lazy. Bug reporters, whether they are developers or not can get quickly hacked off with being told that an error they’ve found isn’t actually a bug, but it’s the fact that it’s actually been implemented exactly to spec.

A bit of common sense in all of this is definitely required. If you need an adding function, it’s obvious to anyone that it should return the result. If the spec doesn’t say so, just do it and move on.

And if you need a function to return the results of whether a visitor is a mobile device or not, it’s probably wise to actually return the value rather than store it in a cookie. Oops!

Post By Rich Gubby (29 Posts)

Tea Drinker Extraordinaire

Website: →


Be Sociable, Share!
Tags: , ,

2 Responses to “When is a bug not a bug?”

  1. Ian Dominey says:

    Well, technically, your friend was right. But then so are you. Ultimately the example that you gave was a flaw in the specification but it was also a flaw in the release process. Having regular contact with the end user throughout the development life-cycle would have fixed that problem. E.g. “I’ve implemented the add thing that you wanted, does this look correct to you?” long before releasing it and then updating your unit tests with the newly discovered requirement would have saved a lot of time.

    I wince at your use of the term ‘common sense’ however. Assumptions, even the most obvious and innocuous seeming ones can come back to bite you more often than you’d think.

  2. Rich Gubby says:

    You’re right, of course. Actually having contact with the end user and asking is what anyone normal would have done.

    But in this particular situation regular contact wasn’t something that was available and was almost frowned upon (even though the end user was internal staff)..

Leave a Reply