Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!usc!ucsd!pacbell.com!ames!sparkyfs!hercules!fernwood!portal!cup.portal.com!cliffhanger
From: cliffhanger@cup.portal.com (Cliff C Heyer)
Newsgroups: comp.software-eng
Subject: Re: recap so far
Message-ID: <31719@cup.portal.com>
Date: 14 Jul 90 21:18:00 GMT
References: <268462df> <39400111@m.cs.uiuc.edu> <114@smds.UUCP>
  <269b7b9d.5643@petunia.CalPoly.EDU>
Organization: The Portal System (TM)
Lines: 213

John A. Sauter 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"
You have COMPLETELY missed my point. This is not the same use 
of "construction" as I used. I was using "construction" in the
context of an "assembly line". What you speak of is a PROTOTYPE.
Engineers routinely build prototypes. This is not like the work a 
contractor does. A contractor has a set of components that an
engineer has already chosen and a plan (blueprint) where an engineer
has determined HOW to fit the components together.

This is nothing like what an engineer does with a prototype. The
engineer has NOT yet selected the components, that is what is job is.
He has no plan for assembly, his job is to determine that. As he does
his job, he builds a prototype.

>whereas the construction worker is responsible for "constructing
>the real object". 
True, but this has nothing to do with my point.

>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).
But HOW they work with them is different. Just because I hold a $100
bill, do I say I am like Donald Trump?

>Software is such an intangible thing. ...with building models and therefore 
>can best be seen as an engineering discipline.  
Yes. There is no "construction" (contractor) phase because all you have
to do is copy the software to a new disk. The prototype or model IS your 
end product. With other engineering fields, you take the prototype or 
model and build an assembly line or hire a contractor (construction).

>Even after reaching this conclusion I don't think I'm any further ahead in 
>approaching this problem!
You're farther along than you think! 

>Talking to
>my HW engineering friends I find that they are faced with deadlines
>and schedules just like I am. 
I think we have to make another distinction here of some engineering
being "production" in nature. That is, every year GM makes a car
that is similar to 1000's of previous cars. There is already a
"book of standard times" that describes how long it takes to engineer
a car. If something can't be done, they revert to last year's design
(that did work.)

When I discussed HW engineering I was referring to engineers 
creating something "new" such as the first electronic watch. NOT
the 1000th electronic watch. There IS a difference!! After 
engineering thousands of cars, GM has a pretty good idea how
long it takes to engineer a car.

With software, there is no such situation. A software firm such
as Ashton-Tate or anyone else does not make 100% new dBase
every year from scratch. There is no history to estimate by as 
with cars. Each project is like the first electronic watch. 

>Do you think GM is going to delay a
>new product introduction 6 months because some engineer ran into a
>design problem? ... throw people at ... If that fails they always
>have something to fall back on: use last year's design. 
This is a luxury that software engineers don't have, because they
don't have such a long history (90 years) of engineering to go
by. 

>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).
With your description of GM, yes. But again, I was speaking of engineering
where management has no prior experience to gauge by. (eg. the creation 
of the first oxygen sensor).

>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). 

The conclusions I have come to so far is that engineering that has 
been done before many times can be somewhat estimated, but not 
to the degree of accuracy as a contractor's standard book of times,
because the development component of engineering is not fixed. 
I asserted software creation is engineering and the development
component means we cannot ever expect accurate estimates.

>I think the social problems are the
>most difficult to solve. 
Software has not evolved
to the point where anyone can agree on what standard components 
should be created. The situation is that many programmers take
pride (get satisfaction from) in devising their "own" way of
doing things. This is because software is unique in that we can 
create components ourselves, rather than needing specialized
manufacturing equipment. This fact will make software harder to
standardize than probably anything in the past.

>I am more likely to use
>a library component if it solves a problem I am not personally
>interested in solving. 
Exactly. Part of the fun of programming is the programmer has the
freedom to try different things and please himself. Take this away,
and probably half the programmers won't want to be programmers
any more.

>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).  
SO WAS I!!!!  The only thing is, THIS HAS NOT CHANGED!! With MS-DOS
we still have the 640KB limit. I routinely do assembler and save 20-60KB
here and there replacing C library routines. On a 386, you can feel
the difference - the assembler makes a program cook compared to
doing things in C. The C compiler generates such verbose assembler
that many times it's a joke. Whether you're talking about Windows,
OS/2 or UNIX, assembler still makes a HUGE difference!

>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.
As far as I'm concerned, a programmer that does not know assembler
is not a programmer if performance is a concern. I can spot code 
written by a computer scientist w/o assembler knowledge in a second.
They don't understand how to code to save machine cycles.


++++++++++++++++++
I'd like to comment on a previous poster's comments regarding
the making of guns during the Civil War. At the time, the 
industry was resisting the introduction of standardized components
in gun manufacturing.

This is NOT like the current OOP dilemma. The gun problem
dealt with converting from custom piece fabrication to 
assembly line. There is no "assembly" phase to programming.
Gun makers were making custom guns piece by piece, just
as if one made a prototype car over and over again. Obviously
this would be an extremely expensive way to make a car, a
gun, or anything.

So some wise chap realized that each of the components could
be stamped out by a machine, and then assembled, thus saving
much time and money.

This analogy suffers from the same error I have been discussing
from the start - that is people mistake programming for
assembly. I say again, IT IS NOT! Assembly assumes that an
engineer has already selected the components and devised
a procedure for assembling them. Programming IS the process
of selecting components, and CREATING components, and
then devising a way to assemble them (glue logic). 

OOP will fail to produce component-based software manufacture
because there is no "manufacture" component to programming.
Engineering can't be automated, until we have computers that
are just like people.
+++++++++++++++++
>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. 
And once you select them, you still have to program to make them
work; hence there is no "assembly".

It is often cheaper to just write non-portable code than to figure out
the objects to use them!

John Dudeck writes:
>This brings up the importance of the compiler in being able to do global
>optimizations.  This is what is going to save us in the end. 
Well we have a long way to go. With my knowledge of assembly language
I looked into what "optimizers" really do, and came to the conclusion
that all they do is remove code that "good" programmers don't use
in the first place.  In other words, if a programmer really understands
how a processor works, he will write code that the optimizer can't
optimize (except for removal of stack probes, etc.). I could only
conlude that an optimizer is a band-aid for bad programming.

>What you call the "layering effect" is a negative aspect of what is the
>otherwise highly desirable goal of decomposition of a problem into
>cohesive, loosely-coupled chunks.  The more we can increase the
>the more advantages we gain in terms of programmer efficiency on the
>long term, maintainability, etc.  On the other hand, each layer of
>abstraction involves adding a layer of indirection to the code.

I think layers=problems sometimes too. In C on my 386, whenever
I use the debugger to see what the code does, I note a typical user
call to a Microsoft library function results in about 20 calls to 
lower and lower level routines, until finally you get to the 
assembler instruction/BIOS call that does the work. I replace these
10,000 lines of library assembler with a 100 lines I code myself,
I reduce my executable by 20KB and my program cooks. I remove
all those layers of conditionals and go right to the low levels and
do what needs to be done.

>Creating software that meets the users needs, is robust and
>maintainable, and is delivered in a timely manner is worth the overhead
>of the ineffeciencies that may be incurred by reuse.  
This is true!!!

Cliff