please coin a term for a lower order bug

[Roedy Green]

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

 

[Stefan Ram]

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

scratch

 

[Ian Pilcher]

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

 

[Eric Sosman]

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.

 

[glen herrmannsfeldt]

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

 

[Arved Sandstrom]

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

True. But until this slow or confusing behaviour violated a business or
technical requirement it's no bug at all. After all, what is "slow"? And
"confusing" to who?

AHS

 

[Lew]

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]

(The software purveyors' pusillanimous retreat behing "Not
warrantied for any particular use whatsoever" is beneath contempt.)

There's a difference between a claim and a warranty. The phrase "not
warranteed for any purpose" doesn't mean that the product won't work or that
they don't think it will, it means you won't get any money if it fails. I
don't think that's beneath contempt; on the contrary I think it's entirely
worthy of contempt.

 

[George Neuner]

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

 

[Jim Janney]

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

What about one that makes it more confusing and needlessly faster?

 

[markspace]

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.

 

[markspace]

What about one that makes it more confusing and needlessly faster?

"Needlessly faster" as in the customer didn't need a speed improvement
in that feature? I'd say that's Gold Plating.

<http://en.wikipedia.org/wiki/Gold_plating_(software_engineering)>

 

[Eric Sosman]

What about one that makes it more confusing and needlessly faster?

That, we call "Progress."

 

[David Lamb]

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.

 

[markspace]

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

 

[Arved Sandstrom]

The fact that the program is being called slow and confusing
demonstrates that it is neither "fast enough" nor "clear enough."
If the program were satisfactory, nobody would be complaining --
but they are complaining, ergo the program does not meet expectations.

Who's "they"? I run into this situation often enough, particularly with
respect to application performance. 9 times out of 10 the people who
complain about slowness haven't measured the current performance,
haven't any baseline data for the performance of any previous versions,
and there are zero business/technical requirements that define target
performance. In the absence of all that the complaint is entirely
subjective, and there is no defect.

I'd be surprised if _you_ set out to "improve" performance without a
specified, agreed target at a minimum.

As for "confusing", if it's a trained user of the program who's
complaining, for some common-sense value of "trained", then maybe I'll
take the complaint seriously. "Trained" to me means that the program
_documentation_ is adequate or better, that the user is familiar with
it, and that if proper operation of the program also requires other
knowledge (like that of business processes, or of some subject, or of
some professional occupation) that the user possesses that knowledge.

I've seen way too many people complain that something is "confusing"
about an application where they lack any of these prerequisites. I'm
sorry, but they can go suck eggs until they do their bit first.

In a more active way you take care of "confusing" by getting user
interfaces (command line, graphical etc) and use cases and storylines
out in front of the user community as soon as possible. This should
happen in requirements at the latest. That's where the prospective users
have their opportunity to eliminate the "confusing" bits.

Note that some bugs are addressed by means other than changing
the code. We might, for example, relabel the program as "Only for
use on big honkin' screamerboxen" or "Not for use by addlepated
nitwits." That is, sometimes the failure to fulfill expectations
is remedied by better control of the expectations. Nonetheless, it's
a bug until and unless *something* is done.

I'll agree that it could be viewed as a requirements defect, sure. OTOH,
if the business signed off on the requirements documents, it's really a
change request.

(The software purveyors' pusillanimous retreat behing "Not
warrantied for any particular use whatsoever" is beneath contempt.)

I agree. But I don't think we're talking about that here. I know I'm not.

AHS

 

[Gene Wirchenko]

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

 

[Gene Wirchenko]

Who's "they"? I run into this situation often enough, particularly with

respect to application performance. 9 times out of 10 the people who
complain about slowness haven't measured the current performance,
haven't any baseline data for the performance of any previous versions,
and there are zero business/technical requirements that define target
performance. In the absence of all that the complaint is entirely

Agreed to here.

subjective, and there is no defect.

Not quite. It may be real but unproven. You and I want proven.

And for that matter, it might well seem slower, but not be any
slower. I have had this happen to me personally. It is embarassing
to me when I measure to prove my point, and the two numbers are the
same or nearly so. Real numbers, please.

I'd be surprised if _you_ set out to "improve" performance without a
specified, agreed target at a minimum.
Quite.

As for "confusing", if it's a trained user of the program who's
complaining, for some common-sense value of "trained", then maybe I'll
take the complaint seriously. "Trained" to me means that the program
_documentation_ is adequate or better, that the user is familiar with
it, and that if proper operation of the program also requires other
knowledge (like that of business processes, or of some subject, or of
some professional occupation) that the user possesses that knowledge.

And that the user is making a reasonable effort to use the
program. "It doesn't work!" does not count for much with me when I
can make it work, or when others can.

I've seen way too many people complain that something is "confusing"
about an application where they lack any of these prerequisites. I'm
sorry, but they can go suck eggs until they do their bit first.

OK, I just said that, too.

In a more active way you take care of "confusing" by getting user
interfaces (command line, graphical etc) and use cases and storylines
out in front of the user community as soon as possible. This should
happen in requirements at the latest. That's where the prospective users
have their opportunity to eliminate the "confusing" bits.

I would also like a solution from the user. What would solve the
confusion problem? The answer need not necessarily be detailed, but
"I don't know. Just make it better." will not do.

There was an example from decades ago where having some entry
forms which specified the units of measure did the trick.

I'll agree that it could be viewed as a requirements defect, sure. OTOH,
if the business signed off on the requirements documents, it's really a
change request.
Yes.

I agree. But I don't think we're talking about that here. I know I'm not.

I get leery of warranting something considering how vague the
"specs" can be in the first place.

Sincerely,

Gene Wirchenko

 

[Lew]

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]

Slower _is_ an effect on results.

"Needlessly faster" as in the customer didn't need a speed improvement in that
feature? I'd say that's Gold Plating.

<http://en.wikipedia.org/wiki/Gold_plating_(software_engineering)>

Only if it is superfluous code. Some very relevant and proper code makes
things faster, such as use of a good algorithm. It isn't necessarily gold
plating.