Re: short-circuit control forms

["Marc A. Criley" <mcqada@earthlink.net>]

Marin David Condic wrote:
> 
> However, I can see your point about minimizing the exposure to possible
> undetected errors. Still, I would prefer to fix the errors up front - or
> never put them in to begin with. But that starts opening up the question of
> what level of testing is good enough? And is it better for your reputation
> to have an occasional flakey error cause a system crash and have enormous
> difficulty reproducing the conditions for you to detect & correct it or is
> it better to have more frequent crashes in early deliveries and have an
> easier time of detecting the problems & fixing them?  (Presuming, of course,
> that this isn't Mission Critical software we're discuissing.) I think it
> might depend on your individual situation. (In house customer vs general
> public, cost of failures, etc.)

The original version of a shipboard weapon control system I worked on
had myriad exception handlers and checks for conditions that should not
have been able to occur, but did, and so were trapped and worked
around.  Needless to say, with the root causes left unaddressed, over
time the system's operation got more and more corrupt and degraded,
until it finally couldn't hold up any more, and would just lock up or
crash.

In the redesign of that system, exception handlers were permitted only
for those exceptions whose raising was anticipated as part of "normal"
failure operations.  And work-arounds to handle anomalous occurrences
were strictly barred.  As a result, the system under development crashed
more frequently than the extensively band-aided one it was going to
replace.

This caused consternation amongst program management, because they
thought the redesigned system was supposed to be better than the
original.  At the last presentation I made to the customer I explained
why we were getting the crashes:  We were finding the bugs _now_,
instead of following the previous practice of having the test group
uncover them and send problem reports back through a longer analyze and
fix cycle.  Our streamlined fix/test process was turning around bug
reports in a day.  And instead of patching and hoping it would hold
through test, we were getting close to having a twisted view of system
crashes--we almost liked them, because it flushed out another bug and we
had scads of log data available to quickly zero in on and fix the
problem.

When we delivered the system a few weeks later, there was only one
low-priority bug report open against the system, and it was an order of
magnitude better in performance, reliability, and understandability than
its predecessor.

Marc A. Criley
Senior Staff Engineer
Quadrus Corporation
www.quadruscorp.com