Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #11140 > unrolled thread

please coin a term for a lower order bug

Back to article view | Back to comp.lang.java.programmer

Contents

  please coin a term for a lower order bug Roedy Green <see_website@mindprod.com.invalid> - 2012-01-09 14:02 -0800
    Re: please coin a term for a lower order bug Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2012-01-09 14:18 -0800
      Re: please coin a term for a lower order bug bugbear <bugbear@trim_papermule.co.uk_trim> - 2012-01-10 09:18 +0000
      Re: please coin a term for a lower order bug George Neuner <gneuner2@comcast.net> - 2012-01-10 11:46 -0500
        Re: please coin a term for a lower order bug David Lamb <dalamb@cs.queensu.ca> - 2012-01-10 16:00 -0500
          Re: please coin a term for a lower order bug markspace <-@.> - 2012-01-10 13:38 -0800
            Re: please coin a term for a lower order bug Gene Wirchenko <genew@ocis.net> - 2012-01-10 15:14 -0800
        Re: please coin a term for a lower order bug Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2012-01-10 18:01 -0800
      Re: please coin a term for a lower order bug markspace <-@.> - 2012-01-10 08:52 -0800
        Re: please coin a term for a lower order bug Lew <noone@lewscanon.com> - 2012-01-10 17:52 -0800
          Re: please coin a term for a lower order bug Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2012-01-10 19:44 -0800
            Re: please coin a term for a lower order bug Gene Wirchenko <genew@ocis.net> - 2012-01-10 20:35 -0800
          Re: please coin a term for a lower order bug Roedy Green <see_website@mindprod.com.invalid> - 2012-01-11 10:54 -0800
    Re: please coin a term for a lower order bug Ian Pilcher <arequipeno@gmail.com> - 2012-01-09 17:29 -0600
    Re: please coin a term for a lower order bug Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-01-09 21:26 -0500
      Re: please coin a term for a lower order bug glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-01-10 02:43 +0000
        Re: please coin a term for a lower order bug Lew <noone@lewscanon.com> - 2012-01-10 07:01 -0800
          Re: please coin a term for a lower order bug Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-01-11 03:23 -0600
          Re: please coin a term for a lower order bug Wanja Gayk <brixomatic@yahoo.com> - 2012-01-15 13:21 +0100
            Re: please coin a term for a lower order bug Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-01-15 08:39 -0500
              Re: please coin a term for a lower order bug Patricia Shanahan <pats@acm.org> - 2012-01-15 06:39 -0800
      Re: please coin a term for a lower order bug Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-01-10 06:45 -0400
        Re: please coin a term for a lower order bug Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-01-10 07:54 -0500
          Re: please coin a term for a lower order bug Lew <noone@lewscanon.com> - 2012-01-10 07:13 -0800
          Re: please coin a term for a lower order bug Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-01-10 18:17 -0400
            Re: please coin a term for a lower order bug Gene Wirchenko <genew@ocis.net> - 2012-01-10 15:23 -0800
          Re: please coin a term for a lower order bug Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-01-11 03:30 -0600
            Re: please coin a term for a lower order bug Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-01-11 08:08 -0500
              Re: please coin a term for a lower order bug Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-01-11 14:38 -0600
                Re: please coin a term for a lower order bug Gene Wirchenko <genew@ocis.net> - 2012-01-11 15:48 -0800
        Re: please coin a term for a lower order bug Roedy Green <see_website@mindprod.com.invalid> - 2012-01-11 11:01 -0800
          Re: please coin a term for a lower order bug glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-01-12 01:45 +0000
            Re: please coin a term for a lower order bug Gene Wirchenko <genew@ocis.net> - 2012-01-11 18:05 -0800
    Re: please coin a term for a lower order bug Jim Janney <jjanney@shell.xmission.com> - 2012-01-10 09:52 -0700
      Re: please coin a term for a lower order bug markspace <-@.> - 2012-01-10 09:51 -0800
        Re: please coin a term for a lower order bug Lew <noone@lewscanon.com> - 2012-01-10 18:08 -0800
          Re: please coin a term for a lower order bug Gene Wirchenko <genew@ocis.net> - 2012-01-10 19:30 -0800
            Re: please coin a term for a lower order bug Lew <noone@lewscanon.com> - 2012-01-10 22:11 -0800
              Re: please coin a term for a lower order bug Gene Wirchenko <genew@ocis.net> - 2012-01-11 15:52 -0800
            Re: please coin a term for a lower order bug Jim Janney <jjanney@shell.xmission.com> - 2012-01-11 13:38 -0700
      Re: please coin a term for a lower order bug Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-01-10 14:05 -0500
    Re: please coin a term for a lower order bug v_borchert@despammed.com (Volker Borchert) - 2012-01-11 20:59 +0000
      Re: please coin a term for a lower order bug Gene Wirchenko <genew@ocis.net> - 2012-01-11 15:53 -0800
    Re: please coin a term for a lower order bug Fredrik Jonson <fredrik@jonson.org> - 2012-01-12 06:59 +0000
    Re: please coin a term for a lower order bug Wanja Gayk <brixomatic@yahoo.com> - 2012-01-15 12:45 +0100

Page 1 of 3  [1] 2 3  Next page →

#11140 — please coin a term for a lower order bug

What would you call a flaw in a program that had no effect on the
results, but needlessly made the program slower or confusing?
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
If you can't remember the name of some method, 
consider changing it to something you can remember.
 

[toc] | [next] | [standalone]

#11142

On Mon, 09 Jan 2012 14:02:33 -0800, Roedy Green wrote:

> What would you call a flaw in a program that had no effect on the
> results, but needlessly made the program slower or confusing?

IMHO it's a mistake to classify such bugs as "lower order". Rather, they
are simply a different subset of the broader classification of "bug":

  * "correctness bug" -- affects the actual result
  * "performance bug" -- affects the efficiency/speed of the code
  * "maintenance bug" -- affects the readability of the code (makes it more
confusing)

I don't think there's any need for a whole new term. It's just a matter of
applying the appropriate qualifier to the existing term of "bug".

Pete

[toc] | [prev] | [next] | [standalone]

#11159

Peter Duniho wrote:
> On Mon, 09 Jan 2012 14:02:33 -0800, Roedy Green wrote:
>
>> What would you call a flaw in a program that had no effect on the
>> results, but needlessly made the program slower or confusing?
>
> IMHO it's a mistake to classify such bugs as "lower order". Rather, they
> are simply a different subset of the broader classification of "bug":
>
>    * "correctness bug" -- affects the actual result
>    * "performance bug" -- affects the efficiency/speed of the code
>    * "maintenance bug" -- affects the readability of the code (makes it more
> confusing)
>
> I don't think there's any need for a whole new term. It's just a matter of
> applying the appropriate qualifier to the existing term of "bug".

+1, and nicely put.

  BugBear

[toc] | [prev] | [next] | [standalone]

#11181

On Mon, 9 Jan 2012 14:18:49 -0800, Peter Duniho
<NpOeStPeAdM@NnOwSlPiAnMk.com> wrote:

>On Mon, 09 Jan 2012 14:02:33 -0800, Roedy Green wrote:
>
>> What would you call a flaw in a program that had no effect on the
>> results, but needlessly made the program slower or confusing?
>
>IMHO it's a mistake to classify such bugs as "lower order". Rather, they
>are simply a different subset of the broader classification of "bug":
>
>  * "correctness bug" -- affects the actual result
>  * "performance bug" -- affects the efficiency/speed of the code
>  * "maintenance bug" -- affects the readability of the code (makes it more
>confusing)
>
>I don't think there's any need for a whole new term. It's just a matter of
>applying the appropriate qualifier to the existing term of "bug".
>
>Pete

Technically a "bug" is where the implementation deviates from the
specification.  Correctness bugs exist and performance bugs exist
assuming there is a requirement for a certain level of performance ...
"as fast as possible" isn't a specification.  

OTOH, I have no idea what constitutes a "maintenance" bug as described
above.  Confusing code is not a bug - it's simply confusing.  Coding
style does not itself *have* bugs, but bad style can *create* bugs.

YMMV,
George

[toc] | [prev] | [next] | [standalone]

#11187

On 10/01/2012 11:46 AM, George Neuner wrote:
> On Mon, 9 Jan 2012 14:18:49 -0800, Peter Duniho
> <NpOeStPeAdM@NnOwSlPiAnMk.com>  wrote:
>> IMHO it's a mistake to classify such bugs as "lower order". Rather, they
>> are simply a different subset of the broader classification of "bug":
>>
>>   * "correctness bug" -- affects the actual result
>>   * "performance bug" -- affects the efficiency/speed of the code
>>   * "maintenance bug" -- affects the readability of the code (makes it more
>> confusing)
>
> Technically a "bug" is where the implementation deviates from the
> specification.  Correctness bugs exist and performance bugs exist
> assuming there is a requirement for a certain level of performance ...
> "as fast as possible" isn't a specification.

I no longer have the reference at hand, but aeons ago I recall reading a 
paper that used basically the same qualifiers as Peter but applied them 
to the word "flaw" instead of "bug;" that avoids the glitches George 
mentioned.  In particular it avoids the issue of whether a "performance 
flaw" is a "bug" (mismatch to specs) or just something one might want to 
fix were there time for it.

[toc] | [prev] | [next] | [standalone]

#11189

On 1/10/2012 1:00 PM, David Lamb wrote:

> I no longer have the reference at hand, but aeons ago I recall reading a
> paper that used basically the same qualifiers as Peter but applied them
> to the word "flaw" instead of "bug;"


Other terms might be "issue" (like, "I have an issue with the way this 
code works), or "undesirable feature."

In a bug-base, these are sometimes referred to as RFEs (Request for 
Enhancement) as opposed to bugs or RFCs (Request for Change).

[toc] | [prev] | [next] | [standalone]

#11195

On Tue, 10 Jan 2012 13:38:41 -0800, markspace <-@.> wrote:

>On 1/10/2012 1:00 PM, David Lamb wrote:
>
>> I no longer have the reference at hand, but aeons ago I recall reading a
>> paper that used basically the same qualifiers as Peter but applied them
>> to the word "flaw" instead of "bug;"

     Yikes!  That is just asking for confusion.  Is a bug a flaw?
Sure.  Is a flaw a bug?  Quite possibly.

>Other terms might be "issue" (like, "I have an issue with the way this 
>code works), or "undesirable feature."

     "issue" would work for me.  It does not imply an error in the
code.  It might be, but it might be lack of training (or mistraining)
of the user, a different configuration is required, or _____.

>In a bug-base, these are sometimes referred to as RFEs (Request for 
>Enhancement) as opposed to bugs or RFCs (Request for Change).

     Another good way to put it.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#11203

On Tue, 10 Jan 2012 11:46:14 -0500, George Neuner wrote:

> Technically a "bug" is where the implementation deviates from the
> specification.  Correctness bugs exist and performance bugs exist
> assuming there is a requirement for a certain level of performance ...
> "as fast as possible" isn't a specification.  

If you want to define "bug" narrowly, you are free to.  Language is fluid.

Just don't imagine that you have the only correct, useful definition of
"bug".

> OTOH, I have no idea what constitutes a "maintenance" bug as described
> above.  Confusing code is not a bug - it's simply confusing.  Coding
> style does not itself *have* bugs, but bad style can *create* bugs.

"Coding style" certainly can have bugs, inasmuch as the code does not
comply with existing style documents/conventions and enforcement tools.
Beyond that, I believe it possible to make objective statements regarding
the clarity and maintainability of code, and to define low qualities of
either as a "bug".

"Maintainability" is particularly easy to describe as a bug, given that we
have good tools for making reasonable measurements of maintainability (e.g.
those that look at things like code coupling, call graphs, etc.).

If you can write a specification for it (and for the things I mentioned,
you can), then you can require code that complies with the specification,
and declare code that does not as having a "bug".

> YMMV,

Indeed.

Pete

[toc] | [prev] | [next] | [standalone]

#11183

On 1/9/2012 2:18 PM, Peter Duniho wrote:
> On Mon, 09 Jan 2012 14:02:33 -0800, Roedy Green wrote:
>
>> What would you call a flaw in a program that had no effect on the
>> results, but needlessly made the program slower or confusing?
>
> IMHO it's a mistake to classify such bugs as "lower order". Rather, they
> are simply a different subset of the broader classification of "bug":
>
>    * "correctness bug" -- affects the actual result
>    * "performance bug" -- affects the efficiency/speed of the code
>    * "maintenance bug" -- affects the readability of the code (makes it more
> confusing)
>
> I don't think there's any need for a whole new term. It's just a matter of
> applying the appropriate qualifier to the existing term of "bug".


Actually, trying to read between Roedy's lines, I think I might know 
what he means by "lower order."  "Lower" as in further down the list of 
things that must be done.  Stuff that totally breaks your code must be 
dealt with promptly, stuff that's just a little slow can wait and is 
lower on the list of stuff to do.

However, I'd call that a "priority," and I'd usually associate it with 
the RFC/RFE that describes the bug.  That is, priority is something 
that's determined by the organization, and isn't always inherent in the 
type of bug itself.  Slow performance might actually be a very important 
bug, high on the to-do list, depending on the organization's over-all goals.


RFC priorities I'm used to seeing:

Critical - Test inhibitors.  These must be fixed NOW.

High - Customer defects for which there is no work-around.  These must 
be fixed before release.

Medium - Customer defects which have a work-around.  These may be 
no-fixed and forwarded to customer support.  These bugs may also be 
forwarded to maintenance or to the follow up project ("version 2.0").

Low - Noise.  These bugs will not be fixed or forwarded.

[toc] | [prev] | [next] | [standalone]

#11202

On 01/10/2012 08:52 AM, markspace wrote:
> On 1/9/2012 2:18 PM, Peter Duniho wrote:
>> On Mon, 09 Jan 2012 14:02:33 -0800, Roedy Green wrote:
>>
>>> What would you call a flaw in a program that had no effect on the
>>> results, but needlessly made the program slower or confusing?
>>
>> IMHO it's a mistake to classify such bugs as "lower order". Rather, they
>> are simply a different subset of the broader classification of "bug":
>>
>> * "correctness bug" -- affects the actual result
>> * "performance bug" -- affects the efficiency/speed of the code
>> * "maintenance bug" -- affects the readability of the code (makes it more
>> confusing)
>>
>> I don't think there's any need for a whole new term. It's just a matter of
>> applying the appropriate qualifier to the existing term of "bug".
>
>
> Actually, trying to read between Roedy's lines, I think I might know what he
> means by "lower order." "Lower" as in further down the list of things that
> must be done. Stuff that totally breaks your code must be dealt with promptly,
> stuff that's just a little slow can wait and is lower on the list of stuff to do.
>
> However, I'd call that a "priority," and I'd usually associate it with the
> RFC/RFE that describes the bug. That is, priority is something that's
> determined by the organization, and isn't always inherent in the type of bug
> itself. Slow performance might actually be a very important bug, high on the
> to-do list, depending on the organization's over-all goals.
>
>
> RFC priorities I'm used to seeing:
>
> Critical - Test inhibitors. These must be fixed NOW.
>
> High - Customer defects for which there is no work-around. These must be fixed
> before release.
>
> Medium - Customer defects which have a work-around. These may be no-fixed and
> forwarded to customer support. These bugs may also be forwarded to maintenance
> or to the follow up project ("version 2.0").
>
> Low - Noise. These bugs will not be fixed or forwarded.

None of these should be tolerated.  Yes, you triage to assign priority, but as 
an industry we have this attitude that it's OK to have some bugs in a system 
as long as they're "lower-order" enough.  That's stupid.  You may never 
actually getting around to fixing a low-priority bug, but if so that's because 
you've got too many high-priority bugs to have the budget to fix the rest, and 
that's obviously a bad thing.  No bugs are good; none should be tolerated.

If you have a process that creates bugs, you cannot achieve this very 
reasonable and proper goal of zero bugs.  You will never achieve it by being 
better at fixing bugs, IMHO, only by preventing them.  That's where unit tests 
and integration tests (by which I mean all tests that integrate units, such as 
end-to-end tests, functional tests, and so on) come in.  Use these right and 
prevent bugs so that you don't have to make up silly terms like "unimportant 
bug" or "lower-order bug" or "low-priority bug".

You can start by eliminating warnings from your code - they are warning you 
for a reason and should be considered errors.  Use good algorithm design and 
checkpoint your invariants ('assert'!).  Keep code simple and cohesive.  Have 
excellent and complete tests.  Don't make excuses for allowing bugs to live.

You should increase priority on each bug that lasts another release - kind of 
an inverse "tenured generation".

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[toc] | [prev] | [next] | [standalone]

#11212

On Tue, 10 Jan 2012 17:52:30 -0800, Lew wrote:

> None of these should be tolerated.  Yes, you triage to assign priority, but as 
> an industry we have this attitude that it's OK to have some bugs in a system 
> as long as they're "lower-order" enough.  That's stupid.  You may never 
> actually getting around to fixing a low-priority bug, but if so that's because 
> you've got too many high-priority bugs to have the budget to fix the rest, and 
> that's obviously a bad thing.  No bugs are good; none should be tolerated. [...]

That's certainly a commendable ideal.  But IMHO impractical.  Any
non-trivial code will always have bugs in it.  Many of those bugs, no one
will even know about.

More to the point, any change to the code can lead to new bugs.  Even new
bugs that remain unknown.  A low-/no-impact bug that you know about can be
a better option than a more serious bug you don't know about, introduced
when trying to fix the bug you did know about.

Many bugs have no material impact on the actual usefulness/correctness of a
program, and there is a finite amount of developer time that can be applied
toward working on the code.  In the real world, it's an acceptable tradeoff
to permit some low-priority bugs to remain in return for applying the
finite developer time to fixing more-important bugs, adding more-important
features, and/or reaching a "good enough" state of the code in time for a
deadline.

To say that every single known bug absolutely must be fixed is simply
unrealistic, in a real world production environment.

> If you have a process that creates bugs, you cannot achieve this very 
> reasonable and proper goal of zero bugs.  You will never achieve it by being 
> better at fixing bugs, IMHO, only by preventing them.  That's where unit tests 
> and integration tests (by which I mean all tests that integrate units, such as 
> end-to-end tests, functional tests, and so on) come in.  Use these right and 
> prevent bugs so that you don't have to make up silly terms like "unimportant 
> bug" or "lower-order bug" or "low-priority bug".
> 
> You can start by eliminating warnings from your code - they are warning you 
> for a reason and should be considered errors.  Use good algorithm design and 
> checkpoint your invariants ('assert'!).  Keep code simple and cohesive.  Have 
> excellent and complete tests.  Don't make excuses for allowing bugs to live.
> 
> You should increase priority on each bug that lasts another release - kind of 
> an inverse "tenured generation".

All good suggestions.  But none support the claim that no bug should ever
be left unfixed.

Pete

[toc] | [prev] | [next] | [standalone]

#11213

On Tue, 10 Jan 2012 19:44:32 -0800, Peter Duniho
<NpOeStPeAdM@NnOwSlPiAnMk.com> wrote:

>On Tue, 10 Jan 2012 17:52:30 -0800, Lew wrote:
>
>> None of these should be tolerated.  Yes, you triage to assign priority, but as 
>> an industry we have this attitude that it's OK to have some bugs in a system 
>> as long as they're "lower-order" enough.  That's stupid.  You may never 
>> actually getting around to fixing a low-priority bug, but if so that's because 
>> you've got too many high-priority bugs to have the budget to fix the rest, and 
>> that's obviously a bad thing.  No bugs are good; none should be tolerated. [...]
>
>That's certainly a commendable ideal.  But IMHO impractical.  Any
>non-trivial code will always have bugs in it.  Many of those bugs, no one
>will even know about.

[snipped rest of comments]

     I agree with your comments including the snipped ones, but
markspace's statement of "Low - Noise.  These bugs will not be fixed
or forwarded." is not acceptable either.

     I grant that low-priority bugs may normally not be looked at
unless they are obvious, but personally, if it is not too much
trouble, when I am working in the area, I will go after such bugs.
Ordinarily, I do not bother.

     It is like picking up an extra item at the store since you were
there anyway.  You would not make a special trip for it, but since you
are there, you get it.

[snip]

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#11233

On Tue, 10 Jan 2012 17:52:30 -0800, Lew <noone@lewscanon.com> wrote,
quoted or indirectly quoted someone who said :

>None of these should be tolerated.

I think that goal is quite reasonable for any code I have been writing
recently. However, it would be rather impractical if MS offered me the
job of whipping Windows 7 into shape to imagine I could ever get it
bug free.
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
One of the most useful comments you can put in a program is 
"If you change this, remember to change ?XXX? too".
 

[toc] | [prev] | [next] | [standalone]

#11147

On 01/09/2012 04:02 PM, Roedy Green wrote:
> What would you call a flaw in a program that had no effect on the
> results, but needlessly made the program slower or confusing?

papercut

-- 
========================================================================
Ian Pilcher                                         arequipeno@gmail.com
"If you're going to shift my paradigm ... at least buy me dinner first."
========================================================================

[toc] | [prev] | [next] | [standalone]

#11155

On 1/9/2012 5:02 PM, Roedy Green wrote:
> What would you call a flaw in a program that had no effect on the
> results, but needlessly made the program slower or confusing?

     Call them "bugs."  Sub-classification as "venial bugs" and
"mortal bugs" just reveals the classifier's lack of imagination.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#11156

Eric Sosman <esosman@ieee-dot-org.invalid> wrote:
> On 1/9/2012 5:02 PM, Roedy Green wrote:
>> What would you call a flaw in a program that had no effect on the
>> results, but needlessly made the program slower or confusing?

>     Call them "bugs."  Sub-classification as "venial bugs" and
> "mortal bugs" just reveals the classifier's lack of imagination.

In health-care systems the difference might be more significant.

-- glen

[toc] | [prev] | [next] | [standalone]

#11174

glen herrmannsfeldt wrote:
> Eric Sosman wrote:
>> On 1/9/2012 5:02 PM, Roedy Green wrote:
>>> What would you call a flaw in a program that had no effect on the
>>> results, but needlessly made the program slower or confusing?
>
>>      Call them "bugs."  Sub-classification as "venial bugs" and
>> "mortal bugs" just reveals the classifier's lack of imagination.
>
> In health-care systems the difference might be more significant.

?

A bug is a bug.  Most shops where I've worked categorize bugs by severity or 
urgency to triage the order in which they repair them.

All bugs have an effect on results, or they aren't bugs.  That's because the 
definition of a bug is unexpected and undesired behavior of the system, i.e., 
an effect on results.

All bugs have the potential to kill if the system is life-supporting.  Not all 
health-care systems have that potential, at least not immediately.  For 
example, one Medicare system out there (more than one, really) is a 
health-care system whose primary purpose is to issue payments to providers and 
to report on providers' effectiveness.  No bug in that system will immediately 
kill anyone or even cause them physical pain, unless it goes unresolved for so 
long that, say, a dialysis clinic has to close.

So health-care systems are not exceptional.  The term you might have wanted 
was "mission-critical" systems.

Still, a bug is a bug.  Even compiler warnings have the potential to lead to 
catastrophic results.  No bug is safe to leave unfixed.  Because undesired, 
unintended behaviors are bad.  Bad!

So all bugs are sinful, venial and mortal alike, and none should be tolerated. 
  Don't write bugs.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[toc] | [prev] | [next] | [standalone]

#11220

Lew <noone@lewscanon.com> wrote:
> 
> A bug is a bug.  Most shops where I've worked categorize bugs by severity or 
> urgency to triage the order in which they repair them.

Some bugs are dangerous, some are costly, some are annoying, some are
just unesthetic. Some bugs are temporary, others are entrenched, some
bugs exists but will not be triggered in the lifetime of the
system. Some bugs are confirmed, others are unconfirmed. Some bugs are
expensive to fix, others are cheap. Some bugs are worth fixing, some
are not.

You should only fix a bug if the value of the fix is greater than the
cost of the fix (although either or both the value and the cost may be
negative). That is not always the case. Sometimes, particularly for
bugs in APIs or libraries, you _can't_ fix a bug, because doing so
would break other people's code.

-- 
Leif Roar Moldskred

[toc] | [prev] | [next] | [standalone]

#11336

In article <jehjrs$3ba$1@news.albasani.net>, noone@lewscanon.com says...

> A bug is a bug.  

If something runs correctly, but slower than necessary, but still 
acceptable, how can it be a bug? A bug, in my view, is a clear defect: 
Does not work like expected, Period.
Everything else, which is okay, but still asks for some polish is no bug 
for me, it's an issue of some sort, a feature-request or an improvement 
waiting to be made, a flaw or an annoyance at worst.

> Most shops where I've worked categorize bugs by severity or 
> urgency to triage the order in which they repair them.

Having said the above:
Even though I would not call these flaws a "bug", I would treat them 
exactly the same way as bugs with the same priorities, which may be even 
higher than a bug's priority. Even if it might sound insane in the first 
place, there may be flaws which are more important to fix than some 
bugs, just an example. Imagine some in-house software, where software 
sales are not the first concern:

1. Program crashes once a month and sends an hour of work down the 
drain: Needs fix, no doubt about it! Major PITA.

2. User complain about shitty usability every day, which costs each 
individual one approximately half an hour per week: More important than 
the crash, because it's way more expensive for the company.

Kind regards,
Wanja


-- 
..Alesi's problem was that the back of the car was jumping up and down 
dangerously - and I can assure you from having been teammate to 
Jean Alesi and knowing what kind of cars that he can pull up with, 
when Jean Alesi says that a car is dangerous - it is. [Jonathan Palmer]

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

[toc] | [prev] | [next] | [standalone]

#11339

On 1/15/2012 7:21 AM, Wanja Gayk wrote:
> In article<jehjrs$3ba$1@news.albasani.net>, noone@lewscanon.com says...
>
>> A bug is a bug.
>
> If something runs correctly, but slower than necessary, but still
> acceptable, how can it be a bug?

     As a preliminary, let's note that the phrase "but still
acceptable" was not part of the bug description until you added
it.  With that in mind, on to the story:

     In 1981 I was peripherally involved with a system that did
interactive searches of a newspaper's content.  (If that doesn't
sound remarkable, take note of the era: Before Google, before Yahoo,
before Altavista, before the Web itself, before the first IBM PC.)
One gang of PDP-11 computers handled the searching, and another gang
digested the newspaper's daily data flow and updated the indices.

     At one major metropolitan newspaper, the system was running
smoothly and doing its job pretty much as intended.  Sure, there
were hiccups, but they did not seriously inconvenience the system's
users or operators.  Yet despite the mostly correct functioning, the
installation was an abject failure.  Why?

     Because feeding one day's worth of copy through the indexer took
about twenty-eight hours.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web