views:

901

answers:

26

We've probably all heard the programming cliché "That's not a bug; that's a feature." I know my question may seem off-topic, but I think it's an interesting question nonetheless.

I'm just getting caught up on the Stackoverflow podcast, and in Episode 21 (at around 27:20, (transcript here) Jeff talks about the developer who wrote the scoring code for Rock Band and how there were ways to score that he didn't even understand. I found that very interesting, and it brought to my mind the question: "Is that a bug, or a hidden feature?" Given that no one will ever write bug free software (or so I believe), my question here is

How do you define the term "bug"?

Is it any time an application does something you didn't expect? Must it be catastrohpic? Something else entirely?

+11  A: 

I define "bug" as "behavior which deviates from the specification."

mbac32768
Then why do I get bugs reported that aren't specifically in the spec?
Quibblesome
This means that your specification, by definition, has no bugs (unless it contradicts itself).
Trent
@Quarrelsome: perhaps your spec isn't detailed enough. Or perhaps the requirements as delivered aren't what the user really expected.
David Hill
Heh, so I will only change the spec to reflect the behaviour of the bug to fix it. ;)
unexist
+2  A: 

I think any behavior you didn't intend or runs contrary to the spec is a bug.

Bob King
+5  A: 

A bug is cute name for a software defect.

Even Mien
Now, define "defect".
eyelidlessness
defect (a fault or malfunction); defect, shortcoming (a failing or deficiency); defect, fault, flaw (an imperfection in an object or machine); blemish, defect, mar (a mark or flaw that spoils the appearance of something) - hope this helps ;)
Even Mien
A: 

I define it as an error in processing. It could be a wide range of errors from data damage to hardware damage, financial loss, to even death - depending on the use of the system. But, generally, its a part of the software which is not working as defined by the original spec and it somehow got past testing.

Optimal Solutions
+1  A: 

I love the definition of a bug is any behavior that deviates from the specification. But I would add that it's behavior that differs from the true specification, which the specification document may or may not reflect in the real world.

Daniel Papasian
A: 

You've got it. A Software Bug is anything that happens during the execution of the code that is Unexpected or Exceptional, and doesn't match the intended specifications for the application. Not all bugs cause the application to crash.

For instance a bug in a financial application may just cause an employee to get overpaid, it doesn't crash the app, but it sure is something Unexpected that doesn't match the spec.

Chris Pietschmann
A: 

That decision is entirely up to whoever is using the software, be that the tester, the customer in a demo, or the end-user. Waving a specification at a customer and saying it's a feature is not going to help you get more business in the future.

It might be a bug that you won't fix, but it's still a bug.

Airsource Ltd
A: 

In my experience, there's no such thing as a "hidden feature." An unplanned coincidence should not be relied upon as design (or emergence).

For me, the term "bug" works well for actual problems in code, but there are other ways to categorize software defects:

  • Improvement or Tweak - for example, the OK button being labeled "Ok" isn't really a bug, but it's something that should be fixed
  • Enhancement - for example, the spell checker is working, but it could be more performant
  • New Feature - for example, the Widget doesn't do X... not a bug, but something's missing

I would collect all of these, and "bug", into the term defect.

David
A: 

A bug is a behaviour the customer did not ask for and that irritates him so much that he wrote a bug report.

gizmo
In other words ... something that the customer doesn't like. Your task of course is to explain that it is not a bug but a feature :-)
Stephen C
Not really. If a customer ask for something, and, at the end, realize that it does not fit his needs, I don't consider this as a bug, but rather as a requirement change request.
gizmo
A: 

A bug is that part of the code that makes the program behave in an unexpected way, according to the users that have paid for that program.

Gamecat
A: 

A "bug" and a "hidden feature" are more or less the same thing: "a behaviour that is different from specifications" but you call it a bug if you don't like the unexpeced behaviour and you call it a feature if you find it useful. It is all in the eye of the beholder!

Giacomo Degli Esposti
+2  A: 

Be careful: if you define "bug" too narrowly, you'll have cases where the users are clearly upset with the program behavior but it will never be fixed because it "meets spec". Sometimes there are bugs in the spec, too.

I've had management with this attitude, and it wasn't fun. And no, there was no contractual obligation to meet the spec - this was shrink-wrap software, and the spec was created by the engineer doing the implementation.

Mark Ransom
+17  A: 

I'll let Dijkstra answer for me:

We could, for instance, begin with cleaning up our language by no longer calling a bug "a bug" but by calling it an error. It is much more honest because it squarely puts the blame where it belongs, viz., with the programmer who made the error. The animistic metaphor of the bug that maliciously sneaked in while the programmer was not looking is intellectually dishonest as it is a disguise that the error is the programmer's own creation. The nice thing of this simple change of vocabulary is that it has such a profound effect. While, before, a program with only one bug used to be "almost correct," afterwards a program with an error is just "wrong." -- E. W. Dijkstra

Denis Bueno
You should change your quote from a code block to a quote block, so it doesn't have funky coloration.
Wedge
very insightful.
Kolten
A: 

To me, a bug is something that breaks your application. Plain and simple.

I hate bugs.

roosteronacid
A: 

A bug is a defect. Which can include even design defects.

However, I would differentiate between defects in implementation or infrastructure and problems with the feature set of the system. It's possible for software to have horrible, unusable features, but that's not necessarily a bug.

For example, it's not a bug or a defect that a Toyota Camry is not a John Deere tractor. The feature set of the Camry is targeted at a specific market rather than the entire power-vehicle market. Which is perfectly fine, demonstrated by the success of the Camry. In the same vein the Ford Edsel did not have design bugs or design defects, it just had a poor design that was not suitable for the market at that time.

Wedge
A: 

A bug is where the code was not written correctly to meet the spec including common assumptions such as the correct formula for copmuting an average (which a spec would not feel the need to actually spell out).

A bug can also include defects of the spec if and only if they are pointed out by the people who gave the input to the spec to begin with. If the managers asked for a particular behavior but the users don't like how it works, that is not a bug. If no one ever mentioned they needed something to work a particular way during the spec gathering, that is not a bug. Those things are additional features. While they may be important to the users, if they were not specified up front, they are not bugs. This is because a bug is an error on the part of the programmer or analyst. As we are not mind readers (a common assuption I know), we cannot be expected to prgram for all the things the users want but failed to tell us.

Maybe we need to coin a new word to describe errors on the part of the user community in defining what they wanted.

HLGEM
A: 

A bug is when the program/spec/design/etc doesn't match the desires of those who have the authority to decide what the program is supposed to do at the time of implementation.

A hidden feature is when the program/spec/design/etc does something that was not planned, but does not violate the desires of those who have the authority to decide what the program is supposed to do at the time of implementation.


If there is a system to track bugs, however, there should also be a way to track enhancement requests and stakeholder issues that are not bugs.

Enhancements would be adding functionality that was not initially desired by those who have the authority to decide what the program is supposed to do, but has since become desired.

Stakeholder issues would be anything that makes any stakeholder less than 100% satisfied (developers, QA, end users, customers - any stakeholder).

Illandril
+4  A: 

Undesirable behaviour.

It doesn't matter if the behaviour was expected or had anything to do with the specification. Some bugs everybody agrees are bugs, in some cases though whether or not the behaviour is undesirable or not can be a matter of personal opinion.

Scott Langham
+6  A: 

Animalia, Arthropoda, Insecta - Hemiptera. An insect ranging in length from ~0.001m -> ~0.15m with a feeding apparatus (mouth) which utilises suction.

Oh.. you mean a software bug.

Something that occurs in code that should not occur either because

  1. it is contrary to the specification, manual, or commenting block
  2. it causes a program crash / stall
  3. it has an unintuitive interface, for example, target users don't understand it

If there is no specification/manual, that can be a bug in itself. If it's a hobby project, then simply, something that is different to what one had in mind when coded.

Vincent McNabb
Beautiful intro ;)1. specs can be severly incomplete. Don't think so.2. Correct.3. strange...4. "unexpected" is serverly subjective.
Andrei Rinea
Vincent McNabb
A: 

A bug is something that appears to be unexpected, but is in fact an undocumented feature.

Rich Bradshaw
A: 

A "bug" is any identifiable "feature" of a program that reduces it's ability to solve the problem it is supposed to solve.

John Nilsson
+1  A: 

bug : program :: weed : garden


Translation for those who never suffered through the analogy section of the SAT or GRE exams: "bug" is to "program" as "weed" is to "garden."

Adam Liss
A: 

for me a bug does not break applications
actually its just that the program behaves in a manner its not supposed to as opposed to errors which really stops the execution (e.g. the famous BSOD's)

lock
A: 

Big is how application behaves under some cases. Bug is just what we expecting and didn't get it.

A: 

It's not a bug, it's an undocumented feature.

thecoop
A: 

The term originates from an incident at Harvard University in 1947. The maintainers of the Mark II Aiken Relay Calculator had problems with moths crawling into the warm machinery of the computer and shorting out the circuits. They would then have to search out the fault and remove the bug to get the thing working again. On September 9th of that year the log entry had a moth taped to the page with the words: "First actual case of bug being found".

They were the first engineers to use the term "debug" to describe what is now agreed to be the process of finding and removing a problem in the running of a computer. Of course what you consider to be a "problem" can be more subjective than a dead moth. Personally I'd say that if software is doing something the designer or the programmer didn't intend it to do then the term "bug" may apply. However an intended behavior, acting as designed, even if it is considered detrimental by most users, is not usually called a "bug," perhaps a design flaw. Contrast this with an "unintended feature" which differs from a bug only in that users find it useful.

By the way, you can see the original bug for yourself at the Naval Historical Center website.

Michael Mathews