From: rms@miles.com (Rob Schultz)
Subject: Enough statistics, what do we do?
Organization: Miles Inc., Diagnostics Division, Elkhart, IN
Date: Wed, 18 Nov 1992 21:50:32 GMT


Ok, I have to admit that some of the statistics in my last posting
were slightly biased.  For example, the US produces far more military
software than Japan.  The amount of paperwork involved in US military
software is positively astounding, and it drives productivity rates
through the floor.  Even so, the quality numbers and sheer volume of
programming staffs indicate that there are several other countries 
actively seeking to dominate the software engineering field.

It is my opinion that we need to work long and hard at improving
our productivity and our quality standards.

Front-loading the process is the first, and most obvious method of
doing this.  More time spent in defining the requirements of a
product, more time spent in designing a system, can mean less time
spent in coding it.  In fact, through the use of highly structured
designs and automatic code generators, we can almost completely 
eliminate the time spent coding certain types of software.  This not
only reduces the amount of time spent in development (and testing), it
also completely eliminates certain classes of errors.  Automated tools
could be developed that would guide our software engineers through the 
design process and perform automated consistency checking at all levels,
from requirements through low-level design, in much the same way that 
hardware engineers use CAD tools.  Of course, once these tools are
available, there is nothing to keep our foreign competitors from 
using them as well.

We also need to provide all of our software engineers with extensive
training in the most effective methods available for producing sofware,
and provide them with the tools to make use of those methods.  This
is going to require a substantial investment on the part of our
management, which may be very hard for them to swallow, especially
given the short-term profit motive currently running rmapant in US
industry.  The tools required include both the software tools that 
will allow us to front-load our process to this extent, and also
the hardware tools for those tools to run on.  This means high-speed
graphical workstations and high-speed networks, including a national
data infrastructure such as ISDN and/or NREN.  Antiquated methods of
software development using 25x80 ascii terminals connected to a mini-
or main-frame computer at 4800bps or 9600bps simply will not suffice
for the software development needs of our future.  (Yes, I still see
these types of arrangements being used for software development.)

Higher level languages that require fewer statements to accomplish
the same functionality will go a long way to showing productivity 
gains in the programming phase of software development, even if auto-
mated code generators are not used.  Lower level languages should be
used only at the lowest levels of hardware interfaces.

Software re-use is going to become one of the most effective methods
of reducing software cost and improving software quality.  I have
heard time and time again that software re-use is a fantasy, but I 
see those same nay-sayers re-using software every day.  For example,
most programmers I know use code fragments as templates for software
with a similar purpose.  Had that software been developed with re-use
in mind, it could have been incorporated into the new package code, 
design, and test.  How many of us use math libraries or operating system
calls to accomplish things without having to re-code them?  I see no
technical reason for not designing software for re-use.

Of course, there are management reasons for not doing these things.
I repeatedly hear managers saying, "Not on *MY* project," or, "We 
don't have the time or manpower to design some other project's code."
And yet, at the same time, I hear those same managers complaining that 
their software development is taking too long and has far too many bugs
in it.

Well, I guess I have ranted on long enough here, so how about those
comments?  I know you are all just waiting to start pounding on those
keyboards.

-- 
Rob Schultz   At Home:                        At work:          +1 219 262 7206
                      rms@andria.miles.com                        rms@miles.com
      {uunet|iuvax}!gator!miles!andria!rms        {uunet|iuvax}!gator!miles!rms