Okay, most programmers know the story—way back when, somebody found an actual insect inside a computer that was causing a problem. (Actually, apparently engineers have been calling problems “bugs” since earlier than that, but that story is fun.)
But really, when we say “bug” what exactly do we mean?
Here’s the precise definition of what constitutes a bug. Either:
- The program did not behave according to the programmer’s intentions.
or - The programmer’s intentions did not fulfill common and reasonable user expectations.
So usually, as long as the program is doing what the programmer intended it to do, it’s working correctly. Sometimes what the programmer intended it to do is totally surprising to a user and causes him some problem, so that’s a bug.
Anything else is a new feature. That is, if the program does exactly what was intended in exactly the expected fashion, but it doesn’t do enough, that means it needs a new “feature.” That’s the difference between the definition of “feature” and “bug.”
Note that hardware can have bugs too. The programmer’s intention is rarely “the computer now explodes.” So if the programmer writes a program and the computer explodes, that’s probably a bug in the hardware. There can be other, less dramatic bugs in the hardware, too.
Essentially, anything that causes the programmer’s intentions to not be fully carried out can be considered a bug, unless the programmer is trying to make the computer do something it wasn’t designed to do. For example, if the programmer tells the computer “take over the world” and it wasn’t designed to be able to take over the world, then the computer would need a new “take over the world” feature. That wouldn’t be a bug.
With hardware, you also have to think about the hardware designer’s intentions, and common and reasonable programmer expectations. At that level, software programmers are actually the main “users”, and hardware designers are the people whose intentions we care about. (Of course, we also care about the normal user’s expectations, especially for hardware that users interact with directly like printers, monitors, keyboards, etc.)
-Max
Or sometimes because you want the app to be as good or userfriendly as possible, you risk assuming things are bugs in usability, when in fact they aren’t. The problem is your assumptions made without involving the customer. If you’re interested in this point of view of what a bug is see http://firstclassthoughts.co.uk/misc/creativity_killed_the_app.html
cheers,
kasper
I definitely agree. I wrote an article on pretty much exactly that (though your specific point about it happening as “assumptions about usability” is a good one, people definitely do that!).
-Max
Another definition for a bug is: “Anything that isn’t according to specification”
If the design document says you click on the button and there ought to be a modal popup but in the implementation the popup isn’t modal, you’ve got a bug! The programmer probably skipped over the line that said in bold with italics and underlined: “This popup should be modal”.
Well, I think that could be classified under the “specifiers intentions,” which is basically like the programmer’s intentions but on a wider-scale project where the implementer isn’t the “intender.”
However, it’s important to not be so dogmatic to a spec that you violate common and reasonable user expectations. It’s exactly the same point I made above in the blog, but expanded slightly to also apply to any intention, whether it’s the implementer’s or the spec writer’s.
-Max
In Layman Terms, a Bug mean–you f*&ked up on the code.
[…] Here is another good definition of what constitutes a bug. Either: […]
[…] Qualquer erro ou problema em informática é um bug, mas geralmente essa palavra é atribuída a erros de lógica durante o processamento de dados. Os bugs são causados por falhas na lógica do programa ou por uma lógica incompleta. Isso se quer dizer que o código-fonte do programa apresenta algum erro ou está incompleto. A qualidade do software fica comprometida, gerando comportamento inesperado ou incorreto. […]
I think there’s an important line in your slides (https://www.codesimplicity.com/wp-content/uploads/2008/07/code-simplicity-open-source-design.pdf) that belongs in this same post:
“Specs that violate user expectations are spec bugs.”
Example: If you have the concept of “user roles” in your application’s permissions/security subsystem, but each role that you add only adds *restrictions* to the user and doesn’t grant additional permissions (so that an action must be allowed by EVERY role you have or you can’t do it), but if you have no roles at all you can’t do anything…it doesn’t matter how well documented this behavior is, it’s still a bug. That’s not what “role-based permissions” *means.* (This is an actual example, unfortunately, not a made up one.)
[…] a (), pronounce “parentheses!” out loud. It’s what many programmers do to spot a bug on their […]