"Programming for the end of the day" is how I've started
describing an attitude towards programming
which is, I feel,
responsible for a great deal of the mediocre
if not downright bad code which plagues everyone who uses
computers. Mediocre-if-not-downright-bad code is code which is
, or less portable
than it ought to be, or harder to add
to than it ought to be, or brittle
-- it may barely work
today, but it breaks tomorrow, when something else changes.
Someone who programs "for the end of the day" believes some or
all of these things:
If the compiler accepts the code without warning or error, the
code is valid and legal.
If the code seems to run without crashing, it's probably okay.
If the code successfully runs a test case, it's almost
If the QA department puts the code through a test suite and
no tests fail, the code is perfect. Definitely.
A bug that has not been reported does not exist.
Now, the reason these beliefs
are wrong (all of them) is that
there are gobs
of ways in which code can be imperfect but which
don't or haven't shown up... yet.
Needless to say, there are plenty of bugs and nonportable coding
practices which compilers don't detect or warn about.
Needless to say, successfully running a test case,
or even a suite full of test cases, proves only that a program
can handle that finite number of cases correctly;
it does not prove that the program could run every possible case correctly.
Most needless (I hope!) of all to say, a bug that has not been
reported (or even discovered) yet is very much still there, and
in fact the longer it takes to discover, the more subtle the damage it's
likely to do and the harder it's going to be to track down and fix.
Unfortunately, though I keep saying "needless to say", these
things do need to be said, because all too many programmers
believe (or, more importantly, act as if they believe) that the
statements above are true.
Worst of all,
these beliefs are not just wrong: they're dangerously wrong.
The only way to write code that does not have any
(or at least not so many) of those hidden flaws is to be
more than a little bit paranoid, to realize that just because some code
compiles without error and runs without crashing and passes the
most comprehensive test suite you've got so far, does
not mean that it's perfect.
Not even close.
The only way to write robust, bulletproof code is to know what
you're doing, to know what works and what doesn't, more
importantly to know what's guaranteed to work,
and to stick doggedly to it, and to steer clear of everything
that works only by accident, or blind luck, or that might work but you can't be