But could you give me an example of a situation in which someone could
take
"the time to produce good code when bad code would be more
appropriate"?
A simple case is triage: given that resources are almost always
limited[0], should one spend time to fix up an ancillary part past
functioning when the critical parts remain broken?
Another case is "more haste, less speed":
(from a 50 year old document)[1]
There are occasions when it is necessary to write programs which will
be executed in as little time as possible. The programmer should bear
in mind that 10,000 executions of all non-optimum instructions would
take less than 3 minutes longer than 10,000 executions of optimum
instructions. If the programmer spends 15-30 minutes on each routine
to save machine time by optimizing, this time may never be made up in
the actual running of the problem.
The modern non-technical reader should bear in mind that in 2006,
10,000 executions of instructions at this level (10ms per rotational
access?) takes but a fraction of a second. But the advice remains
valid: while the quantities change, the quality of the tradeoff does
not.
There must be old folk-tales which express a similar caution. Can
anyone give me an example?
-Dave
:: :: ::
[0] when measuring a project on the triple (Delivery Date, Quality, and
Features) the folk saying is "pick any two".
[1] "Royal McBee LGP-30 Subroutine Manual", 1957?
http://www.wps.com/projects/LGP-21/Documentation/Subroutine-Manual/
PROGRAMS-9.0-11.0r.pdf
:: :: ::
Considering the abstract meta-value of code - I wonder if coding
itself should
become a profession like medicine.
I imagine it'll be pretty self-correcting: the coder who is hired on
his ability to pronounce the names of a few languages and patterns,
like the doctor who is engaged on his ability to pronounce the names of
a few diseases and symptoms, has a fool for a client.
