Programming for the End of the Day

"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 buggy, or less portable than it ought to be, or harder to add features 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:

1. If the compiler accepts the code without warning or error, the code is valid and legal.
2. If the code seems to run without crashing, it's probably okay.
3. If the code successfully runs a test case, it's almost certainly okay.
4. If the QA department puts the code through a test suite and no tests fail, the code is perfect. Definitely.
5. 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 numbered 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 sure.