From: lamaster@george.arc.nasa.gov (Hugh LaMaster -- RCS)
Subject: Re: Software Factory (was: Re: Do Software Engineers Actualy Do So Badly?)
Organization: NASA Ames Research Center, Moffett Field, CA
Date: Wed, 14 Oct 1992 23:38:46 GMT

In article <9210081531.AA16269@bangalore.esf.de>, graham@bangalore.esf.de (Graham Samuel) writes:
|> I was interested to read in article <1992Oct6.185140.10259@news.arc.nasa.gov>
|> of comp.software-eng Hugh LaMaster's comment that he thinks that:
|> 
|>  `many people have deluded themselves into falsely applying models that come
|>   from manufacturing... there is no such animal [as a Software Factory], and
|>   never has been.  The proper model for software is "project", not "factory",
|>   and in fact, most of the costs are "project design-like" costs, not
|>   "construction-like" costs.'
|> 
|> As Director of a project that actually uses the word `Factory' in its title, I
|> must defend the usage!  

Good!  I was, naturally, hoping to start a discussion :-)

                            The point is that the construction of software does
|> bear some analogy with manufacturing.  This is worthy of a longer discussion,
|> but in brief, two of the key ideas from manufacturing which we feel could be
|> re-used (to coin a phrase!) in software production are those of componentry and
|> process.

There are several dictionary definitions of "factory".  Some are very narrow, and
apply to things like DRAMs and TVs.  Others are so broad that the building site
for a custom-built house could be considered a "factory".  I tend to use an
intermediate definition myself; that is, that a factory mass-produces something-
items which are virtually identical (e.g. automobiles) although the
items may differ slightly (e.g. color).  Now, several thoughtful replies and
posts have pointed out that if every item coming from a factory is customized,
such a distinction may be hard to draw.  If anything, though, manufacturing today
is dealing with larger volumes than ever before, from cars to DRAMs.  The number
of automobile engine/transmission combinations in use today is very small, and
the volumes are very large; likewise, most microprocessors are produced in the 
thousands or not at all.


|> 
|> One of the biggest breakthroughs in the industrialisation of society came when
|> people started to put together standardised components.  Manufacturing today is
|> completely dependent on standardised components and on the whole system that
|> creates and maintains the standards.
.
.
.

True, and software libraries today offer an amazing variety of components from
which to choose.


|> People effortlessly combine thousands of predefined pieces to put together
|> totally new objects: the lack of effort comes from the fact that they know what
|> to expect.  

"Effortlessly", relative to what?  While it is true that I can call SGEMM rather
effortlessly, when I need a good matrix multiply, the cost of my doing that
combining, ie programming, is still far higher than the cost of reproducing
my program.


|> One part of a "Software Factory" therefore is a facility for storing,
|> cataloguing and putting together predefined pieces of software (or
|> specifications, or User Interfaces or any other product of the software
|> production process), and one of the key jobs of researchers in this area is to
|> devise and promote standards and mechanisms to make standardised componentry
|> possible.  If we could get this right, we could vastly increase the confidence
|> of users of CASE in general and thus create a far bigger market for software
|> components 

I submit that the use of software components has been high for at least 20 years,
and people use software components with great confidence.  What they can't seem
to do is accurately estimate the length of time it will take to write the software.   
[footnote].  As has been pointed out by someone else on this newsgroup, the use
of quality software components, instead of writing your own, seems to increase
the *variance* in project time even as it has vastly decreased the *mean* time
to produce the same functionality.  

:


|> The key to this sort of efficiency is explicit understanding of process.  What
|> actions/tasks should be carried out when, with what tools and producing what
|> outputs to meet the manufacturing objectives of the factory.  If the process is
|> sufficiently explicit, it can be automated.
|> 
|> We cannot and do not wish to automate people, but nevertheless the analogy
|> holds.  

Actually, this, IMHO, is exactly where the analogy breaks down!  Consider a modern
workstation factory.  An assembler waits for several trays of materials
to be fetched, each with exactly the right components for the type of workstation
being produced.  When the parts arrive, he spends a while assembling them into a
workstation, which he drops on another tray, and goes back to waiting for the
next set of components to arrive.  Can this analogy fit a programmer?  Imagine a 
programmer sitting idly, reading netnews, waiting for the software components needed 
to be dropped in his lap.  Then, he assembles them, and goes back to reading news, 
waiting for the next components.  

Is this realistic?  No.  The creation of the program, while much more efficient than 
in the past, because of all the software components available, is still a creative 
design process.  And then, instead of repetitively producing copies, the programmer 
only has to do produce one (correct) copy.  The (one) program can be tested and the 
documentation completed, if management is willing to pay for it.  Finally, the program 
can be reproduced at will for pennies (which is why software copying is such a problem.)


                By having an explicit model of process (really an extension of the
|> project plan - 

Indeed, the project plan (or model of a process, if you prefer) is a very telling
use of language, because it is sets the context.  Where else do project plans
appear? (what other disciplines?)

                   much of it re-usable because if follows standard procedures laid
|> down for example in an enterprise's quality systems), with suitable computer
|> support we can offer to a person taking on a particular role in the factory
|> (programmer, project manager, quality manager, unit tester, documentor...) the
|> right documents, files and tools to do his or her job, presented in a clear and
|> user friendly way right there on the screen of the workstation.  Such a
|> collection of information is usually called a work context.  The process model
|> is enacted, that is to say it is operated in real time to provide the
|> appropriate work context for each role holder (of course one person can hold
|> many roles and can be assigned several tasks at any one time).  The enactment
|> allows for feedback, so that the whole system (ultimately supervised by the
|> project manager) can react to events such as delays, difficulties, changes of
|> plan... and be altered accordingly.  This may be more flexible than life at
|> Volvo, but it is essentially a factory-like process.


On the contrary, it is exactly like the process which Volvo engineers use 
to *design* Volvos.  Or computer system companies use to design workstations.
(Or software companies use to design software.  But, in software, the
*complete* design *is* the software!)

|> 
|> Of course none of this addresses directly the `Chunnel' problem - how do you
|> make difficult and essentially innovative work predictable?  I would submit
|> however that it helps, because it reduces the unpredictable part to a mimimum;
|> and it puts the best tools in the hands of the people doing the work.


I am afraid that it actually reduces the predictable part to a minimum, by
streamlining the busywork, thus making the innovative part a larger part of
the whole cost.

|> 
|> Of course there is more to say, but I hope this gives some idea why in this
|> project we are still happy to use the term `Factory'.


And, I hoped, I have explained why I think this use of the term `Factory' is
not appropriate.  

"Software Factory", used in this sense, just means a set of tools designed
to make software design efficient.  Another way of saying "CASE", if you
will.  While, by a broad definition of "factory" this is OK, the use of the 
term "Factory" potentially misleads people into believing that the software 
production process is, could be, or should be, routine, when it 
actually is a creative, innovative, and therefore uncertain, and hard 
to estimate accurately, process.

|>  
|>  
|>  
|>  
|>  
|>    Graham Samuel
|>    Project Director
|>  
|> +---------------------------------------------------------------+
|> | ESF Headquarters                    Tel : ++49+30-820 903 12  |   
|> | Hohenzollerndamm 152                Fax : ++49+30-820 903 19  |   
|> | D-1000 Berlin 33                    Internet: graham@esf.de   |  
|> | Germany                                                       | 
|> +---------------------------------------------------------------+

Footnote:

"...Now return to the title of this paper.  The answer to the question stated is
that in this study it has not been shown that the selected models are accrurate
and can be used for estimating projects.  Other studies [...] yielded similar
results.  Despite the flood of publications on software cost-estimation models,
the authors are not aware of any empirical study that shows the ability of
software cost-estimation models to predict effort and lead time of projects
accurately.  Therefore, they believe that only limited confidence should be put
in estimates that are obtained with a model only."

Excerpted from "Are softwre cost-estiation models accurate?, R.J. Kusters, et al., 
in "The Economics of Information Systems and Software", Richard Veryard, ed.,
Butterworth, 1991.


-- 
  Hugh LaMaster, M/S 233-9,     UUCP:      ames!lamaster
  NASA Ames Research Center     Internet:  lamaster@ames.arc.nasa.gov
  Moffett Field, CA 94035-1000  Or:        lamaster@george.arc.nasa.gov 
  Phone:  415/604-1056                     #include <usenet/std_disclaimer.h>