From: ghm@sserve.cc.adfa.oz.au (Geoff Miller)
Subject: Re: Testing (Was: Do Software Engineers Actualy Do So Badly?)
Organization: Australian Defence Force Academy, Canberra, Australia
Date: Wed, 14 Oct 1992 03:22:58 GMT

phardie@nastar.uucp (Pete Hardie) writes:

>In article <1992Oct13.025849.29887@sserve.cc.adfa.oz.au> ghm@sserve.cc.adfa.oz.au (Geoff Miller) writes:
>>But surely this is the advantage of re-usable code, software libraries
>>and so on.  Not only do they speed up development, but they enable you
>>to construct a system largely from tested components whose behaviour is
>>known.  You can then concentrate on testing how those components interact.

>In my experience, there is rarely a piece of code that can be reused on another
>project 'as is'.  Every project has different data structures, and sorting
>them requires a (slightly) different function - or the original function is
>very baroque.

I qualified my earlier comments by pointing out that our experiences do
differ, but my comments were based on my own experience and not just on
theory.  We have developed a number of routines to facilitate the selection,
viewing and editing of database records and have used these in a several
different applications.  These are used in exactly the same way as system
or library routines.  Indeed, we have now virtually scrapped the idea of
buying a commercial application-generator package because we can do what
we need with our home-grown routines.

I should point out, though, that this has happened not by accident but 
by deliberate policy.  The routines have been developed to be re-usable,
and system design has been done to make maximum possible use of them.
This has in turn prompted enhancement of the original routines and
development of new ones.  To me, this is a fairly good parallel with
electronics  -  you design circuits to make use of commercially-
available components, whose behaviour you know and can validate.  The
difference in software is that I don't have to test my component
(subroutine) against a standard because I am in fact calling the single
standard version from a library.

I would also take issue with your "baroque" comment.  In my experience
the re-usable routines are simple rather than complex.

>One thing that I can say about the idea that software modules can be treated
>similarly to ICs and the like - how many different values can a function
>return, compared to an IC component?  The software has a much greater range
>of values, and this complicates the interconnection of one module to another
>greatly.  An EE knows that all his TTL components return binary signals, and
>s/he can connect the output of a NAND gate to a serial input line without
>concern for breaking the serial input line.  Not so with the return value of
>a sort procedure into the calling procedure.

I don't agree at all.  A function/subroutine does not return an unlimited
range of parameters, although a parameter may be multivalued.  To take the
example of a sort procedure, what does it return  -  a list of sorted
values, delimited in some system-dependent manner, and possibly (IMHO,
desirably) the number of values.  I can very simply test this latter
parameter to determine whether the routine functioned correctly and
appropriately, and process the results accordingly.

Geoff Miller  (g-miller@adfa.oz.au)
Computer Centre, Australian Defence Force Academy
Newsgroups: comp.software-eng