Take the 2-minute tour ×

Actually what is a bug ? any predefined rules?

share|improve this question
Can we have some context? Are you talking from a purely tecnical point of view, or bugs which will get reported on tracking sites? –  Jeremy Nov 24 '10 at 12:45
All bugs are just hidden features :) –  Marco Ceppi Nov 24 '10 at 15:24
I tend to say "undocumented features" rather than hidden :-) –  Little Jawa Nov 24 '10 at 20:18

4 Answers 4

up vote 13 down vote accepted

A bug is:


Here is another good definition of what constitutes a bug. Either:

  1. The program did not behave according to the programmer’s intentions. or
  2. The programmer’s intentions did not fulfill common and reasonable user expectations.

Ubuntu community has a excellent definition for bug in this wiki, especially highlighting the difference between bug and missing features:

A software bug is an error or fault in a computer program which makes it fail to work as it's supposed to. This could be as simple as failing to work at all, or as complicated as a subtly incorrect result [...] Some things aren't bugs, but are missing features that should be reasonably included. Missing features shouldn't be reported as bugs, instead FeatureSpecifications should be written for them.

While it is hard to draw a line separating the two definitions and answer the question is it bugs or missing features?, it is possible to give some guidelines:

  • if it's a problem that would have many details to address, it's likely to be a feature. For example, the inability to write files safely to a modern Windows partition is a missing feature.
  • The inability to write files safely to a ReiserFS partition would be a bug.

The difference between the two assertions is: the first is more widespread (support modern windows FS) and thus can be view as Missing Feature, while the other emphasizes a unique problem (can't write into ReiserFS) - a specific bug.

If you are interested, I recommends you to take a look at the BugSquad team wiki. Fighting bugs is one of the most interesting activities involved in software development cycle, besides being a great learning opportunity :-)


share|improve this answer
nice one, although it's not directly related it's maybe worth mentioning that every bug you wanna commit has to be reproducible. –  danizmax Nov 24 '10 at 15:18
No, there are bugs due to race conditions. Why shouldn't you want to commit them too? It will be hard, if the programmer can't reproduce the bug, but that doesn't affect the wish to do so, does it? –  user unknown Feb 13 '11 at 8:11
Please also refer to the Ubuntu BugSquad's guide on bugs: wiki.ubuntu.com/Bugs –  Thomas W. Jun 12 '12 at 17:43

I'll take a swing. Primarily, behaviour not intended by the designer / programmer (discounting bad design). In terms of what bugs you should report to people, anything which makes the program hrder to use and fits the above description. This includes, from worst to least severe, system crashes, X crashes, program crashes and any internal program bugs.

Bugs which cause crashes or window closures will usually cause some kind of output to stderror if you've run the application from a terminal, this can be useful. Also see system logs for error reports.

share|improve this answer

A bug is an error in a computer program or system, so the program doesn't work properly or doens't work at all. So bugs can be a result of wrong programming code, or programming code that isn't robust enough and can't handle certain exceptions (for example: division by 0)

share|improve this answer

For all practical purposes the term "bug" should be avoided as a too fuzzy term.

The best answer to your question fills a whole book: "Why Programs Fail" by Andreas Zeller. A book that should be on every programmers' bookshelf. The author also makes a good effort in not calling them "bugs" (read on). Because as crncosta's answer already suggests a "bug" isn't just a programming error. This is why some people prefer the term "issue" instead (which leads to "issue tracker" instead of "bug tracker").

Because what's perceived as a bug by an end-user needn't be a bug at all. It can be - even though this is often used as a lame excuse - simply by design. Some failures however, once observed, are classified "bugs", even though they are due to lack of a feature.

The author of aforementioned book spends several pages on the definition of terms such as failure and defect and describing why "bug" is not an appropriate term (too fuzzy).

Summary of his terminology:

  1. programmer creates the defect
  2. defect causes an infection ("faulty program state")
  3. infection propagates
  4. infection causes failure ("observable bad/unintended behavior")
  5. observer (usually the end-user) sees the failure

As you can see the author distinguishes between cause and effect, which in the case of "bug" is almost always mixed. Most of the time the term "bug" is being applied to the defect, the infection and the failure.

share|improve this answer

Your Answer


