Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!cbnews!cbnewsm!lfd
From: lfd@cbnewsm.att.com (Lee Derbenwick)
Newsgroups: comp.software-eng
Subject: Re: Reusability considered harmful??(!!)
Summary: Even with spec sheets, you _always_ prototype the circuit.
Message-ID: <1991Feb18.224524.28236@cbnewsm.att.com>
Date: 18 Feb 91 22:45:24 GMT
References: <88431@tut.cis.ohio-state.edu> <6108@stpstn.UUCP> <1127@TALOS.UUCP>
Organization: AT&T Bell Laboratories
Lines: 60

In article <1127@TALOS.UUCP>, jerry@TALOS.UUCP (Jerry Gitomer) writes:
> jls@yoda.Rational.COM (Jim Showalter) writes:
[ ... ]
> :The odd thing is, people worry about testing inherited code, but they
> :are looking at it wrong, I think. If you have gotten some software that
> :asserts it can be inherited from, you should treat that software like
> :an IC. You don't second-guess Intel, right? If the software DOES break,
> :it should be something you can take to the courts, just as a chip that
> :failed to perform to spec would be grounds for restitution.

You _always_ second-guess Intel (or any other manufacturer) and prototype
the circuit first.  Prototyping mostly catches your own design errors,
but it also catches the case where one particular chip has insufficient
noise immunity or just happens to oscillate _in your circuit_.

Sometimes you modify the circuit; sometimes you find a different
manufacturer whose chip (for the same function) doesn't have that
problem.

> :Until people get comfortable with the idea of off-the-shelf software being
> :just as much of a black box as ANY OTHER COMMODITY, we will continue to
> :battle this weird behavior. Do you second guess anything else you buy?
> :No? Then why second-guess software modules?

Do you buy a car without a test drive?  Do you buy a suit without trying
it on?  Most software is vastly more complex than most things we buy, but
there are still lots of things we test first.

> Although I am comfortable with the idea I am not comfortable with
> using inherited code that I do not completely understand.  To me,
> it sounds like we need some standards that *thoroughly* describe
> the nature and characteristics of the inherited code -- a set of
> engineering specs, if you will.  Something that corresponds to
> the chip vendors data book and fact sheets would probably be the
> way to go.  

The data book helps, but it still never does the complete job.  The
sine routine that someone else mentioned is a good example: its behavior
was good enough on average, but its worst-case error happened to be
around the most critical values for one application.  The spec sheet
is not normally going to give you a chart of error tolerance (or time
delay, or whatever) vs. input values.  And a routine that was
sufficiently accurate for _all_ values would presumably have been
more expensive to execute -- it might well not have been feasible
either.

One big difference is that, for reusing software, we normally have a
single sample that we must either reuse or not.  And even if there are
multiple vendors, we generally have to pay in full for the software if
it meets its published specs, whether or not we end up being able to
use it.

Whereas two or three samples of a hardware component are _much_ cheaper
(sometimes free) than what we will spend once we start manufacturing in
quantity.  So our prototyping lets us find out whether the chip is
useful to us _before_ we've paid for an order of 100,000 of them...

 -- Speaking strictly for myself,
 --   Lee Derbenwick, AT&T Bell Laboratories, Warren, NJ
 --   lfd@cbnewsm.ATT.COM  or  <wherever>!att!cbnewsm!lfd