Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!bellcore-2!bellcore!dduck!duncan
From: duncan@dduck.ctt.bellcore.com (Scott Duncan)
Newsgroups: comp.object
Subject: Re: Overused metaphors - Software ICs, etc.
Message-ID: <25993@bellcore.bellcore.com>
Date: 9 Aug 90 11:41:43 GMT
References: <23915@nigel.udel.EDU> <2088@esunix.UUCP> <5436@stpstn.UUCP> <4078@kim>
Sender: news@bellcore.bellcore.com
Reply-To: duncan@ctt.bellcore.com (Scott Duncan)
Organization: Bellcore, Piscataway, NJ
Lines: 45

In article <4078@kim> kim@spock (Kim Letkeman) writes:
>
>In many of these "paradigm shift" or "software IC" or "product versus
>process" arguments, the basis is a flawed analogy. One simply cannot
>compare the extremely complex software creation process with anything
>that is manufactured in the more traditional sense.

I fully agree since I don't believe there is ANY manufacturing in software
development.  As others have suggested in their posts back as far as June,
software development is an "engineering" activity.  It leads to creation of a
(somewhat) custom system "prototype."  In software, we can replicate the
prototype without any tooling, assembly line, etc. since it is an almost
totally non-physical thing being copied.

>I'm certain that OOP will make a huge dent in the way in which
>software is built in the future, but I can't believe that it will
>completely replace existing methods in every situation.

I think more and more traditional application (as opposed to algorithm)
development will depend on greater use of existing components.  I do not
think the software industry can survive financially without such improvements.
However, it will be in order to customize software more easily, not to create
identical copies for the mass market -- that we can do already with far less
cost than any manufactured product.

I think we need to expend more effort understanding the potential impact of OO,
etc. on design, rather than implementation, issues in software.  The one thing
about software that just about everyone understands is that it is physically
possible to do almost anything with it and that individual physical changes to
software are easily accomplished.  Hence, we find that the limitations and
constraints in software (as opposed to other engineered items) are mostly those
of human comprehension/understanding and group coordination/communication.

Many software engineering efforts in the reuse and OO arena seem aimed at
saving resources in implementation of software.  Yet the largest number of
problems in a software system seem to be traceable back to requirements and
design flaws.  I feel the impact of OO technology (and associated reuse
advantages claimed) will be in making it easier to explore design more easily
and eliminate ambiguities in requirements by allowing more iterations of the
prototyping cycle in software.

Speaking only for myself, of course, I am...
Scott P. Duncan (duncan@ctt.bellcore.com OR ...!bellcore!ctt!duncan)
                (Bellcore, 444 Hoes Lane  RRC 1H-210, Piscataway, NJ  08854)
                (908-699-3910 (w)   609-737-2945 (h))