please coin a term for a lower order bug

[Gene Wirchenko]

Slower _is_ an effect on results.


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.

If the speed was not required and the change was made to increase
the speed, then it is goldplating.

I often write code that is not optimal for speed, because it is
easier to maintain. If the code had to be faster, I would modify it.
If it is fast enough, why bother? There are enough other things to
do.

Sincerely,

Gene Wirchenko

 

[Gene Wirchenko]

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

 

[Lew]

If the speed was not required and the change was made to increase
the speed, then it is goldplating.

That's a good way to tell the difference. We weren't talking about changes,
we were talking about flaws, but regardless. No one posited that the change
was not required, nor that it was made for the purpose of increasing speed.
It is quite possible to make a change that is required or has a functional
purpose that also, and inevitably, makes the program faster. Then it is not
goldplating.

Applying your litmus test can tell the difference.

I often write code that is not optimal for speed, because it is
easier to maintain. If the code had to be faster, I would modify it.
If it is fast enough, why bother? There are enough other things to
do.

Quite so. But speed is not something to avoid, either, not if it is a byblow
of better algorithm and smarter coding. It is as dangerous a religion to shun
speed in the name of not prematurely optimizing as it is to chase it prematurely.

There is also more than one metric of speed. When you do optimize for speed,
make sure it's the right kind. I've seen performance choke on something sped
up for the single-thread case when the target environment was heavily
multithreaded. Lock contention cascades non-linearly after a threshold.
Individual service response time is not the same as system throughput.

Strangely (not), such premature optimizations were also horrid code with no
functional purpose. To call them gold-plating does them too much credit.
More like poop plating. A correct algorithm would have omitted the premature
gold-, er, poop-plated monstrosity. And been both easier to maintain and
faster. And used less memory.

Gene, I agree with your points. But let us not swing too far the other way
and eschew non-premature early optimization. Correct logic more frequently
than not creates maintainable, fast and memory-efficient code as an emergent
consequence.

 

[Eric Sosman]

Or it demonstrates that the commentator doesn't understand the scope
of the problem the program deals with.

They've been snipped from your response, but I think my
remarks about controlling expectations cover this case. Look
for the paragraph beginning "Note that some bugs are addressed
by means other than changing the code."

Observe that this approach to managing context is not unique
to software. It's a "bug" that some powerful medications come
in the form of colorful pills that small children may mistake
for candy. The response is not to alter the medicine's potency,
but to inform adults that the product is NOT to be operated by
children.

 

[Roedy Green]

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]

After all, what is "slow"?

there are two different kinds of slow.

1. unoptimised. You don't do this until you prove a need for it, and
you do it at the end.

2. stupidly slow. e.g. calling a method twice in succession for no
reason, using a bubble sort when a perfectly decent sort is built n
squared algorithms that can't possibly scale to what will be required.

There is a snob attitude to DELIBERATELY waste resources, picking the
inefficient technique even when the programmer knows a better one that
is no more difficult. This is how we manage to make computers with
3000 times the computer power less responsive that XTs.

 

[Jim Janney]

If the speed was not required and the change was made to increase
the speed, then it is goldplating.

I often write code that is not optimal for speed, because it is
easier to maintain. If the code had to be faster, I would modify it.
If it is fast enough, why bother? There are enough other things to
do.

I focus on making the code clear before anything else. Then I make sure
it's correct -- this is much easier when it's already clear. Then, if
it turns out to be necessary, I worry about making it fast -- again,
this is much easier if you have clear correct code to start from.

First rule of performance tuning: the problem is never where you thought
it was going to be.

 

[Volker Borchert]

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

As always, that depends. Examples:
- If "slower" means that realtime requirements are not met,
the bug is a "blocker".
- If "slower" means that application sluggishness annoys my
boss while he's playing around, the bug will probably become
"critical" sooner or later.
- If "slower" means that application sluggishness annoys users
enough to start them nitpicking on other issues, the bug is at
least "major", depending on the importance of the customer.
- If "slower" means that an quarterly job takes two hours three
seconds instead of two hours, the bug is probably "not-a-bug".

 

[Gene Wirchenko]

I'm just saying that there are people whose expectations are beyond
control.

BANG!

Any others?

Sincerely,

Gene Wirchenko

 

[Gene Wirchenko]

[snip]

Gene, I agree with your points. But let us not swing too far the other way
and eschew non-premature early optimization. Correct logic more frequently
than not creates maintainable, fast and memory-efficient code as an emergent
consequence.

I do not think that we are disagreeing at all.

Often, the reasonable effort is <adjective> enough. If you
really need the extra and are willing to pay for the resulting hair in
the code, then it gets messy.

If nothing else, youhave a pre-hair version in case the
conditions requiring the hair go away.

Sincerely,

Gene Wirchenko

 

[Gene Wirchenko]

As always, that depends. Examples:
- If "slower" means that realtime requirements are not met,
the bug is a "blocker".
- If "slower" means that application sluggishness annoys my
boss while he's playing around, the bug will probably become
"critical" sooner or later.
- If "slower" means that application sluggishness annoys users
enough to start them nitpicking on other issues, the bug is at
least "major", depending on the importance of the customer.
- If "slower" means that an quarterly job takes two hours three
seconds instead of two hours, the bug is probably "not-a-bug".

No. Each of your examples does affect the results.

Sincerely,

Gene Wirchenko

 

[glen herrmannsfeldt]

(snip on ways to make programs slow)

2. stupidly slow. e.g. calling a method twice in succession for no
reason, using a bubble sort when a perfectly decent sort is built n
squared algorithms that can't possibly scale to what will be required.

Some are not so obvious.
Building long strings with strcat() in C is O(n**2).
I once had to find and fix this in a program that put together
megabytes one line at a time.

There is a snob attitude to DELIBERATELY waste resources, picking the
inefficient technique even when the programmer knows a better one that
is no more difficult. This is how we manage to make computers with
3000 times the computer power less responsive that XTs.

My favorite one to complain about is programs that read in a whole
data set to process, when it could be done just as well one record,
or small group of records, at a time.

-- glen

 

[Gene Wirchenko]

On Thu, 12 Jan 2012 01:45:34 +0000 (UTC), glen herrmannsfeldt

[snip]

My favorite one to complain about is programs that read in a whole
data set to process, when it could be done just as well one record,
or small group of records, at a time.

Or where rows in a database are processed record-style (all being
read to the client and then written back) when the whole shebang could
be dealt with in an SQL statement.

Similarly, when local recordsets are run through for matching
rows instead of selecting with a condition in the first place.

Sincerely,

Gene Wirchenko

 

[Fredrik Jonson]

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

A performance bug or a usability bug. Performance and usability can be
as important as correctness. As others have pointed out in this thread
it all depends on what quality requirements you have on the system.

Now, to answer the question in the subject of your post: A buglet.

https://en.wiktionary.org/wiki/buglet

It interesting that the word buglet sounds a bit corny - at least to
my non-native english. Almost as if it was intended, to point out that
buglets really doesn't always need fixing and might almost as well be
characterized as a part of the personality of the system.

 

[Eric Sosman]

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.