Path: utzoo!mnetor!uunet!husc6!bloom-beacon!mit-eddie!uw-beaver!tektronix!decvax!mandrill!nitrex!rbl
From: rbl@nitrex.UUCP ( Dr. Robin Lake )
Newsgroups: comp.software-eng
Subject: Re: Who builds tools?
Message-ID: <743@nitrex.UUCP>
Date: 9 May 88 13:35:55 GMT
References: <321@uwslh.UUCP> <40335UH2@PSUVM> <2539@orca.TEK.COM>
Reply-To: rbl@nitrex.UUCP ( Dr. Robin Lake )
Organization: BP America Research and Development
Lines: 55
Summary: Personal Experiences with Building and Using Tools

In article <2539@orca.TEK.COM> stank@orca.UUCP (Stan Kalinowski) writes:
>
>I have just finished a project where I was a toolsmith.  Looking back,
>I must say that that creation of a tools team was probably one of the
>best ideas I've seen in software engineering in a long time.  Let me
>describe the problems that my engineering organization faced.
> ... excellent rules of thumb and guidelines omitted for brevity ...

I got bitten by the "tools" bug a long time ago (some code first done in
1973!) when UNIX was first generally available outside of Bell Labs.  Since
then, I've taught and enforced the tools concepts through two graduate
programs I ran and also seen its value in industrial-strength projects the
last 6 years.

In addition to the fine suggestions in the above article, an important aspect
of software-engineering-with-tools is to incorporate the tools concepts
into the DESIGN process.  If you have a good structured design discipline and
your designers KNOW the tools that are on the shelf, the design results in
modules that are ALREADY CODED AND TESTED!!  A few pieces of glue here and
there and a new module or two  --- but if your tool-kit is robust, there is
probably a module there that only needs a few lines changed in order to
meet the new module's specs.

The primary benefit of this approach is that a PROTOTYPE system can be shown
to the user very quickly.  "Is this what you asked for and what you wanted?"
Cuts down on the "moving target" project objective in a major way.

How did we do it  ---  simply  ---  just looked at all I/O in the UNIX way:
a stream of bytes.  Built "orthogonal" tools that did "every" operation 
possible on byte streams.  Ditto higher structures  --  words, lines, ....
Yes, things do get more abstract within some modules, but the designer,
and programmer see just an ASCII stream of bytes and can debug on this basis.
To date, we have about 200 tool modules, the longest being about 5 pages
of C code.

When the modules are piped together to create the system, the system does
run slowly.  But once again, the prototype is up really fast,
the project produces what the user wants, and  ---  egad  --- sometimes the
user accepts the "slow" fast prototype as a final product!  ("If this works
now, why waste any more time on speeding it up?  We can buy a faster machine
for the cost of a man-week of programming effort.")

I did an article on a product developed using the design approach,
using it for hardware/software design decisions,
in IEEE Trans. Biomed Engineering, October 1982. "A High Speed Data Acquisition
Subsystem"

Summary:  Tools work!  Tools work far better if incorporated into the design
process!!

-- 
Rob Lake
BP America Research and Development
decvax!mandrill!nitrex!rbl
mandrill.CWRU.EDU!nitrex!rbl