From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,db5c6b2ef47d4b9e X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-06-22 05:17:24 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!cyclone.bc.net!newsfeed.direct.ca!look.ca!newsfeed1.earthlink.net!newsfeed.earthlink.net!newsmaster1.prod.itd.earthlink.net!newsread2.prod.itd.earthlink.net.POSTED!not-for-mail Message-ID: <3B332A96.64DDB78E@earthlink.net> From: "Marc A. Criley" Organization: Quadrus Corporation X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: short-circuit control forms References: <3B30F836.D700DAA3@raytheon.com> <3B312260.728686B5@boeing.com> <3B3143A2.89CC2841@easystreet.com> <3B320D90.DD4BB9B2@ftw.rsc.raytheon.com> <3B3216D9.113A612B@easystreet.com> <9gtfn7$dl9$1@nh.pace.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 22 Jun 2001 12:17:24 GMT NNTP-Posting-Host: 63.178.185.114 X-Complaints-To: abuse@earthlink.net X-Trace: newsread2.prod.itd.earthlink.net 993212244 63.178.185.114 (Fri, 22 Jun 2001 05:17:24 PDT) NNTP-Posting-Date: Fri, 22 Jun 2001 05:17:24 PDT X-Received-Date: Fri, 22 Jun 2001 05:15:15 PDT (newsmaster1.prod.itd.earthlink.net) Xref: archiver1.google.com comp.lang.ada:9028 Date: 2001-06-22T12:17:24+00:00 List-Id: 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