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