Well, my message (or response) was very tied to the real world. My clients don't care what my
design patterns or thoughts are. If something doesn't work according to their needs or wants, it's
a bug.
I was trying to use the "gray areas" in my message to point out that a "design bug" (BJ's term?)
may or may not be a bug in human perspective, depending on real world conditions (availability of
resources, for eg).
Of course, in IT speak and in a computer's perspective, a function that does not work as designed
is buggy. But try telling that to a customer. "It's not a bug, it's a feature, so would you
please?". :P
Jonathon
David E Jones wrote:
Was this message intended to evoke a response? Well, here it is.
The way I'm used to defining things what you describe is more of an
"issue". An "issue" is anything that represents a difference between
what a user (any user...) needs or wants and what the system offers.
A bug is a totally different animal. When looking at bugs it doesn't
matter at ALL what a user needs or wants, the only thing that matters is
what the current system is designed to offer. If there is something that
the system is designed to offer, or in other words that is already
implemented in the system, but that is not functioning as intended, then
THAT is a bug. Fixing a bug is changing something (usually small,
isolated changes) that exists, not adding anything new.
I may be biased on this one, but I don't really see this as all that
complex. The point for any word is to have a useful definition that
makes distinctions of value in real life. Defining a "bug" as anything a
user doesn't like basically makes a release branch with "bug" fixes only
useless, as it might as well be the trunk. That is a pretty good litmus
test for this definition, IMO.
-David
On Oct 28, 2007, at 12:32 AM, Jonathon -- Improov wrote:
If some function doesn't work according to user needs, then it is a
bug. Period.
Now the gray areas.
If that same function still serves the user's needs if used in some
other ways (albeit not exactly according to user's mouse-clicking
habits), it depends.
If I'm given time and resources to fix the issue, then it is a bug. If
I don't have time and resources to fix it, then it is... erm... not a
bug. :P
Jonathon
BJ Freeman wrote:
Most bugs arise from mistakes and errors made by people in either a
program's source code or its design
we all accept that if the code breaks it is a bug.
For applications that have UI, it is also a failure if the person using
the application is not given the input necessary to put correct data and
then gets an error message say they should. This to me is a design bug.
So I put to you.
is it important to include how a user might use the application
inappropriately if there is not the correct information for the user
interact without getting error messages.
if so is this considered a bug.
