Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!spock!kim
From: kim@spock (Kim Letkeman)
Newsgroups: comp.object
Subject: Re: Overused metaphors - Software ICs, etc.
Message-ID: <4108@kim>
Date: 10 Aug 90 11:22:48 GMT
References: <23915@nigel.udel.EDU> <2088@esunix.UUCP> <5436@stpstn.UUCP> <4078@kim> <8190@fy.sei.cmu.edu>
Organization: Mitel. Kanata (Ontario). Canada.
Lines: 76
In-reply-to: cpp@sei.cmu.edu's message of 9 Aug 90 18:56:27 GMT

In article <8190@fy.sei.cmu.edu>, cpp@sei.cmu.edu (Charles Plinta) writes:
|
| [...]
|
| In article <4078@kim>, kim@spock (Kim Letkeman) writes:
|  >Hmmm ... I would suggest that during the industrial revolution the
|  >cottage industry gunsmiths were merely replaced by more advanced and
|  >efficient methods, not by a plethora of interchangeable parts. 
| 
| But the key here is that a product existed around which the process
| for producing them could be defined.  I wonder if the "baseline"
| product produced by the craftsmen was optimized to allow mass
| production and to allow it to easily be fixed in the field
| (interchangeable parts).  Were these the major design considerations
| for optimizing the baseline product design.  I also wonder which
| came first, product design or process definition.

It's probable that the original processes employed by gunsmiths were
optimized towards manufacturability when you consider the difficulty
of crafting anything with fire, low carbon steel, and a hammer. It's
likely that product design came first as even today it is rare for
processes to be fully defined and documented.

By the way ... the "process versus product" discussion is (IMO) as
flawed as these manufacturing analogies. We are really discussing a
naked compiler versus a full blown environment, as was Brad when he
first coined the process and product terminology (or at least when I
first saw him use it.) The connection to processes and products is
pretty weak (again, IMO.)

| In a lager sense, a suspension bridge is a scalable model also and
| these have been quantified to the point that the driving
| characteristics of a suspension bridge have been isolated, the
| equations captured, and computer programs written to accept the
| characteristics (span, avg/peak weight, wind, etc.) and produce the
| design and parts lists.

I don't think it's possible to compare the complexity of a large
software design project with that of a large bridge design project.

The above paragraph talks about a suspension bridge as a scalable
model, implying that this is one of those "product" units that could
be slotted into place to fit a certain requirement. In fact, I'm sure
that there is only so much flexibility for the architect in adapting
the common implementations to a new situation. (Lessons learned from
bridges like Galloping Gurdey.)

This is in direct contrast with the C3 example (removed for brevity)
where innumerable variations have been implemented to date, few of
which could be certified as high quality with any reliability (again
in contrast to a bridge.) How do we pick the one that is to become the
model? Unfortunately, even if we could, we'd end up with only a small
piece of the puzzle in a typical large system (another contrast.)

| Finally, only after a product architecture (C3 architecture) is
| quantified can we begin to define processes for producing the
| product, refining the product, and define and develop tools for
| automating the process.

I am a bit of a fan of the "peopleware" philosophies put forth by
DeMarco and Lister. Good people develop good systems. Bad people fail.
People in between get widely varying results in widely varying time
frames. (Extreme paraphrasing.) 

There are so many variables in software design (people, tools,
algorithms, languages, target applications, target hardware, egos,
teams, etc) that simple analogies break down quickly.

I pretty much feel that OOP will help good people go even faster and
achieve even higher quality (I'd bet on getting an order of magnitude
in cases where the people are really good and OOP really fits.) Bad
people will continue failing.  And people in between will achieve
varying results. But the overall trend will be upward and that's why
OOP is such a big deal.
-- 
Kim Letkeman    mitel!spock!kim@uunet.uu.net