Fog Creek Software
Discussion Board

Define: bug

This might sound like an obvious or stupid topic but I found out this morning that my current deadline is going to be accelerated so I needed to re-prioritize my task list.

Of course I knew I needed to fix the bugs first!

The problem is, there are say, 25 items on my list; some are hard bugs (you put a alpha in a numeric field and you get a SQL exception) and some are definately features (can you have more than one contact per company), but many fall into a gray area where I might classify them as features, but their absence would in fact qualify as a bug (i.e., the output from the program would be incorrect).

I'm wondering what the rest of you consider to be the line between bugs and features.

Jason J. Gullickson
Monday, November 24, 2003

Does the software function as documented?  If not, it classify it as a bug.

Guy Incognito
Monday, November 24, 2003

If the output, defined in the requirements, of your program is compromised then it is a bug that needs to be fixed.  If it is something extra that will add additional output to your program, i.e. not necessary in order to meet the defined requirements, then you do not need to add that feature.

Simple as long as you did a good job gathering the requirements.

Monday, November 24, 2003

And if your really looking to speed things up... just change the documentation!

Guy Incognito
Monday, November 24, 2003

You should also look at the severity and frequency of a bug and do cost / benefit on it.  If a bug happens once in a blue moon and doesn't really have any negative impacts, you should really be working on other things.

Monday, November 24, 2003

bug n. An undocumented property of a program. See also feature.
-- Devil's IT dictionary

Monday, November 24, 2003

I like tapiwa's answer.

Jason J. Gullickson
Monday, November 24, 2003

It's an Irony but Bug is somethings that keeps us all employed.

So the question is whether we unconsiously create bugs or not.

Cold somewhere in time
Monday, November 24, 2003

Everything that is perceived as a bug by your users.

Jan Derk
Monday, November 24, 2003

Ha ha.

Ill try that on my next demo...

-Also I have taken the liberty to add a very useful feature. This feature lets the user study typical, randomly selected error messages so that they are familiar with them in the unlikely event of a real program error.
The error messages will not tell the user what he did wrong, but rather just give them a number that they have no chance to decipher, JUST LIKE REAL ERROR MESSAGES!

Eric DeBois
Monday, November 24, 2003

Bug vs. feature is mostly a matter of affixing blame. Did the programmer screw up, or did the specs not fully anticipate or describe what was needed?

I say, call 'em all "change requests." Someone doesn't like the behavior of the program, should it be changed? Evaluate based on how strong the benefit is to making the change vs. the cost of making the change.

Some bugs don't really bother anyone, and are difficult and risky to fix. Some feature requests might be trivial to implement and can make the software twice as useful. Who cares who wins the "Is it a bug or is it a feature request?" argument? Just spend your time wisely improving the application...

Steve R
Monday, November 24, 2003

If computer error messages were haikus:

Three things are certain:
death taxes, and lost data.
Guess which has occurred.

Errors have occurred. 
We won’t tell you where or why.
Lazy programmers.

The code was willing.
It considered your request,
but the chips were weak.

Yesterday it worked.
Today it is not working.
Windows is like that.

The Web site you seek 
cannot be located but
endless others exist.

Tuesday, November 25, 2003

I seem to remeber one that goes:

Such a big file.
It might be very usefull.
But now it is gone.

I love it

Eric DeBois
Tuesday, November 25, 2003

For the hacker's definitions of bugs, you need to distinguish between bug, feature, misfeature, wart, and miswart.  Best link for that is:

In general, a bug is any program behavior that differs from user or programmer intent.  If it differs in a bad way, one might call that a "proper" bug.  If it differs in a good way, it's a feature (in the sense of "that's not a bug; that's a feature").

Intent is pretty nebulous, of course.  Someone could have written a program specification, but even that could differ from intent.  Also, since the programmer and user are different people in this case, the user's intent dominates.

So in your case, anything that differs from the user's intent is a bug.  Note that you have three options on each bug: change the code to fit the user's intent, change the user's intent to fit the code, or both.  Use your head, and you'll be fine.

Paul Brinkley
Tuesday, November 25, 2003

*  Recent Topics

*  Fog Creek Home