Hi Beth:
What I say in this forum is often from the standpoint of being a "customer"
who purchases software.
Since I have some exposure to the software industry (I work in it...) I know
that within the industry, a "bug" is just another name for "Defect".
A software Defect/Bug is when the software doesn't do what the customer
wanted.
The problem with adding the term "expected" as in "unexpected behaviour" is
that you can have "unexpected behaviour" that is NOT a defect, and "expected
behaviour" that IS a defect.
But there is only one kind of Defect -- the situation when "the thing
doesn't do what the customer wanted". There can be any number of "causes"
for a Defect -- my previous employer's Defect Management System defined
about 20 of them by the time I left, and the list was still growing. A
piece of software can also have many other kinds of "badness" which are NOT
defects. It may, for example enable users to steal music, or it may contain
pirated code.
"The cause of the defect" is not the customer's concern. All of the
companies involved in getting the software onto the customer's computer (and
their lawyers...) can argue about that until the end of time (and they
will...)
When I experience a defect, at least some of those companies/lawyers will
claim that they "intended" the product to behave that way and that I
"agreed" to purchase it on that basis.
If I had the money to take them to court, I would argue that my agreement
could only be claimed if it represented "informed consent": in other words,
if they told me about the defect before I purchased the software. Since
they "didn't", I did not (in law...) give my consent, and therefore am
entitled to hold their feet to the fire. If I had a few billion dollars to
spare, I would love to run this as a test case. Unfortunately, it would not
produce better software: it would simply produce longer and more convoluted
End User Licensing Agreements
If I made the software and YOU were complaining about it, I would change
hats and speak as an employee within the software industry. You would then
find that I have 30 years practice at making all the bad things that happen
the fault of the customer, and I'm good at it.
But, in this forum, I am usually a Customer. Then, I don't *care* how it
happened. I don't care "what caused it". It's buggy, and I want it fixed
Just as a side issue, only a few per cent of the bugs that make it onto the
shop shelf are caused by "coding errors". Almost all of them occur before
the code was written, and about half of them are "intentional". The most
common cause is "We decided it was too expensive to fix." It is also not
unknown (particularly in the Consumer software market) to find "If we fixed
that, they would have no reason to buy the new one." Or: "If we fixed that,
they would have no reason to buy the professional version."
Cheers
Hi John,
I have just had an epiphany about this entire issue and it's based on two
points on which I hope we can agree:
1. It's all about communication. If we understand the meanings of the
words/terms we use, then we will more easily understand each other.
2. When it comes to the meaning of "bug", you and I, John (or if you
insist, the layperson and the "software industry") are unlikely ever to
agree
.
With me so far?
So let's agree to accept a resolution to this debate that will allow each of
us to understand what the other is talking about.
You say: The software industry understands "bug" to be a slang term for
"defect".** A defect is "an unexpected behavior". There are various types
of defects, chief among them being coding defects, design defects and
specification defects (though there are others).
I say: "Bug" is a slang term for something that does not work as it was
designed to work; that is, the end result intended by the software provider
cannot be achieved because of an error in coding (at least in the vast
majority of cases I'm leaving the door open for another possibility though
I'm not sure there is one). So, basically, bug is a slang term for what you
call a coding defect.
When I (and apparently most others on at least this newsgroup) call
something a bug, you will know exactly what I mean. But when you call
something a bug, I really *don't* know what you mean because you haven't
specified the nature of the bug/defect.
So, in the interests of clarity and communication, if you would use the
terms coding bug (or defect), design bug (or defect), specification bug (or
defect), etc., then we will no longer be in a position to misunderstand each
other's meaning. I can't see how you could object to this since it allows
me to both accept and understand the terminology you prefer to use.
Otherwise, I'm afraid that every time you use the term "bug", I will have to
ask what kind of bug you're talking about in order to comprehend your
meaning. It would sure help if you just specified it in the first place.
Beth
**I have not yet seen convincing evidence that this is the case but I'm
accepting it for the sake of argument.
--
Please reply to the newsgroup to maintain the thread. Please do not email
me unless I ask you to.
John McGhie <
[email protected]>
Microsoft MVP, Word and Word for Macintosh. Consultant Technical Writer
Sydney, Australia +61 (0) 4 1209 1410
