Subscribe in your feed reader
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