What defines a bug

[BJ Freeman]

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.

[Jacopo Cappellato]

Please,

before we start a new useless discussion around trivial issues...
BJ, I've added the "required" labels (to the "Create Person" *and*
"Create Party Group" forms) to the release branch as well.
I hope this will make your life easier now.

Jacopo


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.

[jonwimp]

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.
>
>

[David E Jones]

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.
>

[jonwimp]

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.
>>
>

[BJ Freeman]

Thanks David
I was meant to illicit a discussion so I can find out what the values
are here.
I thought it the best way so I can "fit in".

David E Jones sent the following on 10/28/2007 1:31 AM:

>
> 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.
>>
>

[David E Jones]

For customers, yes, I think it's VERY important to make that  
distinction too. If you have a support contract or they want fixed  
bids it's critical. Even if not it is very valuable for planning and  
setting expectations, basically just good client communication.

-David


On Oct 28, 2007, at 11:28 AM, Jonathon -- Improov wrote:

> 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.
>>>
>

[BJ Freeman]

Just as a note:
in my description I did not interject that a user had defined a bug.
I was talking from UI design only, from a users perspective.
I find the the UI seems to suffer.
I must say though that since 2003 the UI had significantly improved.


David E Jones sent the following on 10/28/2007 12:17 PM:

>
> For customers, yes, I think it's VERY important to make that distinction
> too. If you have a support contract or they want fixed bids it's
> critical. Even if not it is very valuable for planning and setting
> expectations, basically just good client communication.
>
> -David
>
>
> On Oct 28, 2007, at 11:28 AM, Jonathon -- Improov wrote:
>
>> 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.
>>>>
>>
>