[Boulder.pm] Academic vs Production Code

[Rob Nagler]

Ed writes:
> However, how is the credit card analogy related to a program checking
> itself?  Are we talking about simple checks to make sure the correct answers
> are returned from a function?  Or something more involved?

Here's a discussion about Fast Fail (or vice-versa :)

http://en.wikipedia.org/wiki/Fail-fast

Code always makes assumptions, and these need to be checked in
appropriate (not all) interfaces.  The example was opening a file,
which can fail, and if it does, the program has to stop doing
something it should be doing.  Most of the bugs in software are
related to mismatched assumptions.  In this case, the operating system
and language processor assume opens can fail and need to be checked,
but the program is assuming it won't and doesn't check.  Another
approach, which is Pascal-like, is that the language processor fails
for the program.  This is the nanny-state solution, and it doesn't
work either.  You don't want the program to fail when you can't open a
file in an editor; you want it to produce an error message, and ask
the user to correct the file name.

Programmers tend to fear failure.   You can read more about why I
think this is the case, here:

http://www.viarob.com/my/page/The_Psychology_of_Software_Testing

Rob