Re: please coin a term for a lower order bug
Gene Wirchenko wrote:
Lew wrote:
markspace wrote:
Jim Janney wrote:
Roedy Green writes:
What would you call a flaw in a program that had no effect on the
results, but needlessly made the program slower or confusing?
Slower _is_ an effect on results.
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_%28software_engineering%29>
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.
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.
--
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg