From: wicklund@intellistor.com (Tom Wicklund)
Subject: Re: Software Factory (was: Re: Do Software Engineers Actualy Do So Badly?)
Organization: Intellistor, Inc.
Date: Wed, 14 Oct 92 00:16:08 GMT

In <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.'

>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.  When was the last time you ordered a
>screw with a non=standard pitch?  I doubt if even General Motors does this. I
>imagine also the market for railway wagons with a non=standard wheelbase is
>pretty limited too.  And we all know the concept of a standard component has
>reached the world of microelectronics in hundreds or maybe thousands of ways.

The problem with software is it's too easy to create a non-standard
component.  Creating a screw with non-standard threads involves a lot
of metal work.  Re-implementing a software component is normally
fairly simple.  Sometimes it makes sense to re-implement a component.
Back in the mid 70's I did that to some IMSL library routines because
they were very inconstent in their FORTRAN I/O.

On the other hand, how many programmers decide they need to be more
efficient than the component so bypass it.  This was done with the
original IBM PC.  Direct screen writes were used for text I/O rather
than BIOS calls.  I don't think any extra functionality was available,
but it ran faster.  Too many programmers try to optimize everything
rather than just places where performance suffers.

The "not invented here" syndrome is also major.  One doesn't create
screws with non-standard threads just because somebody else designed
them (English/metric arguments aside).  Software is often
re-implemented because the components were built elsewhere.

Sometimes a disguised form of "not invented here", the fear of losing
control of software by using components that somebody else is
maintaining is also large.  For commercial products this involves what
happens if the company fails or drops the product.  Even within an
organization the same fears exist.

Legal problems are another point.  Embedded software is perceived as
having zero cost when producing a product (as opposed to chips, PC
boards, and sheet metal which have per unit costs).  Many
organizations will write their own embedded operating system rather
than pay $1.00 per unit for a commercial one.  Worse, if the
commercial product licenses for $100 per copy, it may be too
expensive.  Object code only licensing can also create problems when
one wishes to make small modifications or extensions (perhaps solved
by use of object oriented languages and inheritence or similar
concepts).

I agree with the software factory concepts as described here.  I
suppose I'm a bit cynical having fought against the various fears of
sharing code between products too many times.