Re: Bugs or Mistakes?

["Robert I. Eachus" <eachus@mitre.org>]

Richard D Riehle wrote:

> Robert Eachus made a very good point in a separate posting about the
> responsibility of a designer of bolts targeted to the construction of
> a bridge.  Is a bolt that cannot handle the stress of its load a "bug?"
> No. We would consider it a mistake.  It is an engineering mistake.

     I was talking about another issue, who is (legally) responsible if
and when the bolts fail.  But since you bring it up, it stands as a very
good example.

     If you design a building, run it through a finite-element
simulation before signing the drawings, and find that the bolts
specified are inadequate, this is a bug in your design, and you fix it
and repeat the simulation.  If the simulation does meet spec, but
someone supplies or uses sub-standard materials or doesn't build to
spec, then they are liable.  (The suspended walkway collapse in St.
Louis and the DC-10 crash on takeoff at O'Hare fall into this category.)

     But if the bolts do meet spec, and the actual conditions don't
match the simulation, then you have the case of the John Handcock
building in the Back Bay.  The wind sometimes blew UP the building, and
sucked out windows.  The solution was to replace the windows with
stiffer windows at significant cost.  Who was at fault?  In this case no
one.  The engineers had not been negligent, they had even tested models
in a wind tunnel.  But the models had not been large enough--and complex
enough--to catch the effects of such things as the fresh water in Back
Bay vs. salt water in the harbor.  The result was that the Handcock
tower was uniquely placed to trigger the uninversion of atmospheric
inversions, and create local updrafts that exceeded the building's
specifications.  The Galloping Gertie bridge failed due to a similar
local trigger, but in that case there was negligence.  The winds were
there before the bridge was built.

    Now we can discuss when a bug is not a mistake.  A bug that never
gets to the field can be the result of a mistake, but often a bug
detected early is just that, a bug.  For example, in Ada it is much more
productive to let the compiler worry about elaboration order, and only
consider it as a problem if the compiler can't find a solution.  If
judicious use of elaboration pragmas can sort it out, was there a
mistake?  Not really.  It is much more efficient to allow the compiler
to select an order to the extent the order irrelevant as long as it is
within the rules.  If you leave off a necessary pragma Elaborate_Body,
and as a result use an uninitialized variable, that is a mistake, even
if you do catch it during unit test.

    What is my point in all this?  A bug may have resulted from many
mistakes or none.  Going around assigning blame for bugs is
conterproductive until you have found what is wrong and why.  It can
also be counterproductive to label as mistakes errors in draft
documents, schedules, or software.  The process of accountability should
only begin when someone signs off on something--or alternatively, when
it is accepted or fielded without competent techincal approval.

-- 

                                        Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...