Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!umich!umeecs!hela!john
From: john@iti.org (John Sauter)
Newsgroups: comp.software-eng
Subject: Re: recap so far
Message-ID: <1990Jul10.134226.22459@iti.org>
Date: 10 Jul 90 13:42:26 GMT
References: <268462df> <39400111@m.cs.uiuc.edu> <31558@cup.portal.com>
Organization: Industrial Technology Institute
Lines: 132

In article <31558@cup.portal.com> cliffhanger@cup.portal.com (Cliff C Heyer) writes:
>The terms
>
>    ***** ARCHITECTURE and ENGINEERING *****
>
>should be used instead of "design" and "construction" respectively. 

I don't necessarily agree that the distinction in terms is that
important.  A hardware engineer works with specifications and models.
His work can easily be described as "constructing a model" whereas
the construction worker is responsible for "constructing the real
object".  They both work with standard building blocks, the engineer's 
building block primarily being intangible objects used to build models
(model used in the more generic sense, not enough room to define here).
Software is such an intangible thing.  What is the final product?  Is
it the binary representation of the program as it is encoded on a
magnetic media embodied in a piece of computer hardware?  Or is it 
a pattern of charges in electronic gates on a circuit board after it
has been copied from disk?  What is involved in the construction of 
the final end product of software.  To my knowledge it is mostly done
automatically and therefore is of little interest to software engineering
(except to those how build compilers, linkers, disk drivers, etc.).
If this is the case then software engineering is primarily concerned
with building models and therefore can best be seen as an engineering
discipline.  Even after reaching this conclusion I don't think I'm
any further ahead in approaching this problem!

>Software
>estimates should be made the same way hardware engineers make their
>estimates.  
>
>Lets discuss hardware estimates.
>Do such estimates allot a fixed amount of time for each chip to estimate
>a board design? (eg. 80386 = 2 weeks, etc.)
>==========
>Engineering deadlines are by default flexible. You can't market a TV
>that does not work, right? Therefore the deadline gets moved whether anyone
>likes it or not. And I see evidence that those engineers are not pressured to the 
>same degree as programmers. Management knows that pressure = errors = 
>delayed completion = increased costs. (But then you have to weed out loafers
>who take advantage of a non-production environment to not produce.)
>==========
I don't think that hardware engineering works this way.  Talking to
my HW engineering friends I find that they are faced with deadlines
and schedules just like I am.  Do you think GM is going to delay a
new product introduction 6 months because some engineer ran into a
design problem?  If there is a problem anywhere, they throw people at
it and resources until it is solved.  If that fails they always
have something to fall back on: use last year's design.  In any case
there is sufficient differences between the realm of HW engineering
and SW engineering that has been discussed at length here.  I don't
believe we will find a solution to our problems from the HW
engineers (except in understanding the need for rigor, structure
and discipline as we have better tools and techniques to work with).

>This is a strong obstacle to component re-use. A managerial
>directive must be enforced, but this may conflict with
>"time to market".
>==========
>We have to look at how people get satisfaction in their work. If a programmer
>gets satisfaction from "using his own code" then obviously he will always
>resist using components. 

I agree that reuse is hard.  There are technical problems (such as 
cataloging for retrieval, finding what you need) and social problems
(NIH on the individual level).  I think the social problems are the
most difficult to solve.  Even the comments in this group from
people actively reusing components tend to emphasize one of two
catagories of software reused:
  1) software written by the same person who is reusing it (the
     programmer who builds up a huge library of reuseable modules)
  2) software that solves an "uninteresting" problem from the
     perspective of the person whi is reusing it.
The second kind is a little more subtle.  I am more likely to use
a library component if it solves a problem I am not personally
interested in solving.  I find DBMS problems B*O*R*I*N*G!  I will
gladly buy, reuse anyone's code so long as it performs reasonably
close to my requirements.  However give me a "standard" linked list
management package and I am very tempted to write my own, optimized 
to managing just the kind of lists I need for my project.  Every
time I look at a standard package I see all the extra baggage needed
to support generality which I consider to be non-essential.  Perhaps
this is due to my "poor" upbringing.  I was raised and nurtured on
6502's and Z-80's in the late 70's and spent many hours squeezing
everything I could out of those puny processors with tight assembly
language code in order to do the kinds of things I needed (real-time
control).  Now when I look at excess code my frugal upbringing rebels
inside of me.  Perhaps I should be put out to pasture and younger
programmers who have been raised on the fat of 40MHz 68030's and
RISC machines which you never touch with an assembler should take
over.  Perhaps these will be less likely to fall to that kind of 
temptation.  But I suspect that even these will have their weak spots
and category #2 will always haunt us.

>Edward J. Prochak writes....
>>My bottomline point is that tuning
>> may not require change source code.
>>It may just as likely involve swapping
>>one object with a similar one having 
>>different performance attributes that
>>better match the application.
>>
>>Does this sound close to being in the ballpark?
>YES! But this is a long ways off! I can't fathom the
>task of trying to standardize components, and then growing
>to a level of sophistication where we could choose different
>flavors of the same components. And doing all this trying to
>interface with billions of lines of code written the "old fashioned
>way." 

I agree.  There is a marketing problem here.  Just to market a single
version of a reasonably complete set of objects for a single programming
domain (say GUI's or DBMS) requires an immense number of objects.
Just browse through the Smalltalk classes for an example.  You could
spend several man-months (even a man-year) just trying to understand
all that is in there.  To suggest that we could have several versions
of each of those classes/objects begins to exceed any human capability 
to successfully market and use that number of objects.  The best
approach is stil the availability of source code for modification, but
alas we run into a greater business problem with that approach.

>You can't gauge the speed and "feel" - that will give you competitive
>advantage - until you've completed a portion of your product. THEN 
>you'll know if your design is worth a hill of beans or not.

AMEN!  That's why I think rapid prototyping is one of the best things
going in software engineering.
-- 

John A. Sauter                         Industrial Technology Institute
Internet: john@iti.org                 PO Box 1485
                                       Ann Arbor, MI 48106