Quotation of the Day

Custom Search

Thursday, July 9, 2009

Software Bugs And Spec Bugs

Let's assume that the error message wasn't displayed. In this case, we have a classic case of a software bug; i.e., a bug born because of a mismatch between the actual behavior of the software and the expected behavior (which is usually specified in the spec).

If you paid a little bit of attention when you read item 2.1., you surely noticed (joke) that it wasn't clear what kind of error message is expected to be displayed-i.e., the decision on the actual text of error message is up to the programmer, and he or she can write code that will produce:

- a NONinformative, irritating message: "Error", leaving the user to wonder what he or she has done wrong and cultivating a feeling of guilt in him or her, OR

- an easy-to-understand message: "Oops, error on page. ZIP code should have 5 digits".

Formally, the programmer will be right in both cases, because the specification doesn't elaborate about the text of the error message.


In early days of start-up when software changes very often, there is no need
to include precise text of error messages into the spec. The idea about error
message will do. For example: "Error message should state that ZIP code should
consist of 5 digits".

Here we have a situation where the spec itself is buggy, because

- we reasonably expect that spec to give us details about the error message, and

- the actual spec doesn't give us those details.

Let's call this situation "spec bug."

Brain positioning

Each found bug (both in software and in specs) must be filed into the bug tracking system.

There should be no exceptions. Bug reporting is one of the most important parts of our profession.

We'll have a separate lecture to talk about bug reporting and tracking.

Brain positioning

From the start, you must understand one very important thing: when

you file a bug against someone, it doesn't mean that you hate

or disrespect that person. It simply means: "I have found mismatch

between actual and expected. Please, fix the problem."

If somebody takes a bug personally, you must have the respect and

patience to explain to him or her that there is nothing personal here -

this is just a part of your job.


Three Conditions Of A Bug's Existence

A bug exists only if ALL of the following three conditions are met:

1. We know the expected result

2. We know the actual result

3. We know that the actual result deviates from the expected result


Every time you see a mismatch between the actual and expected, label that situation with the word "bug." As time goes on, you'll develop a habit, which will gradually grow into a reflex. Please note that for the sake of this training, it doesn't matter how futile, cheap, or temporary your expectations are - the main thing here is to gain the skill of automatic bug recognition.

Example

Here are some more bugs from real life:

1. A nice face backed by an ugly personality.

2. Parrots say the nastiest words at absolutely inappropriate times.

3. Hollywood story: reach fame and drink yourself to rehab.