Fog Creek Software
Discussion Board

Definition of Bug?

For the purposes of a contract, I need a definition of 'bug'.

We've always struggled with this one, as clients typically like to argue that a feature request is really a bug so that it can be implemented for free.

Here's what we've got so far:

"Bug" means an error in coding or logic that causes a computer program to repeatedly malfunction or produce incorrect results that are replicable on demand.

Anyone have anything better?

Thursday, March 27, 2003

Try Google

The first hit gives you a definition.

Matthew Lock
Thursday, March 27, 2003

I think your definition doesn't distiguish what "incorrect" means.    I would define it as not behaving according to a documented specification, but some people take it to mean "not working the way I think it should work".

Thursday, March 27, 2003

You skipped a step.

1) Define requirements
2) If the application does not perform a requirement as defined, that is a bug.

3) If the application *does* perform all requirements as defined, then anything else is an enhancement request.

Skipping step one will *always* hurt the contractor.


Thursday, March 27, 2003

I agree 100% with Philo.

The only way you can distinguish between a new feature and a bug (Error in existing functionality) is if you have clear documentation of the agreed functionality.

Even then, there will still be instances where the distinction between the two is unclear.
For example, a recently deployed system allowed the entry of nett and gross weight for the part.
The spec did not specify that the gross weight had to be at least equal to the gross weight and the programmer had put no such check in. The users had accepted the spec, but said that the relationship was obvious, which it is, and it was fixed as an error in existing functionality. Nonetheless, a strict applying of the guidelines would have classified it as a new feature.

David Burke
Friday, March 28, 2003

The gross weight had to be at least equal to the gross weight?

Brent P. Newhall
Friday, March 28, 2003

No wonder they thought the relationship was obvious.

Friday, March 28, 2003

About obvious relationships,

Sometimes specing doesnt help eliminating the "We thought it would work differently" problem. Agreed that when this happens, its a bad and broken spec.

Spec says

B is equal to C.
A is equal to B.

and then when the program says that A!=U the customer goes; Well...we thought that it would work like A=U also.
This you have to understand without it being speced, since everybody knows that both A and U is wovels.

If some of you have a way of eliminating the problem of what I can call "Unspeced business assumptions" that does not go into specs because they are "obvious" , feel free to share how you make sure this does not happen.

Monday, March 31, 2003

*  Recent Topics

*  Fog Creek Home