From: adams@fanaraaken.Stanford.EDU (Allen Adams)
Subject: Re: What is Software Engineering
Organization: DSO, Stanford University
Date: 12 Aug 92 14:56:17 GMT

kanko@enuxha.eas.asu.edu (Mark Kanko) writes:

>In article <adams.713466914@fanaraaken.Stanford.EDU>, adams@fanaraaken.Stanford.EDU (Allen Adams) writes:

>>                  As one electrical engineer told me, "My job as an engineer
>>  is to make things work, no matter what."  Therefore, my conclusion is

>   This EE does dis-service to his profession.  Every job has constrints.
>   Does '...no matter what...' include 'working' for only 5 minutes before
>   burning out the power supply?  Of course not!  Virtually every H/W effort
>   has reliability and maintainability (R&M) constraints somewhere in the 
>   spec.  Same should hold true for software.  (Hoo-boy.  I can see the
>   defect density and MTBF discussions coming already... ;-) )

>>  is to make things work, no matter what."  Therefore, my conclusion is
>>  that 'hacking' is and should be the job of an engineer.  To 'engineer'
>>  software, as the latest software engineering principle's tell us, really
>>  is not engineering.  Maybe we should call ourselves 'software artists'.
>  
>   Sorry, your conclusion(s) is (are) based on a faulty assumption. 
>   [Or was your whole post a tongue-in-cheek?]

The EE example was intended to show why some engineers think it is 'silly'
to practice the principle's espoused by 'software engineers'.  This
was said during an effort that I was leading where we were converting
software I had written from Pascal to Ada.  The two other main player's
backgrounds in this situation, besides myself, were EE and CS.  The CS
person had done several things in Ada and was trying to approach the
conversion in, for lack of better words, an object-oriented manner (this
was before OOP was the latest buzzword).  The EE (as an aside here, I am
not trying to portray this EE as an example of ALL EEs, just using him
as a reference point) wanted no part of this.  Ada was just another 
language like FORTRAN and he felt that to try and 'software engineer' 
the solution just got in the way of getting his job done on time.
Since I was interested in other things at the time, I let each person
go on the paths they felt more comfortable with.  The exercise, in my
mind, proved that you could develop packages in Ada that can and will
be re-used, as well as a person has the ability to treat Ada like 
FORTRAN and generate code, that might be messy, but 'works' just
like the 'software engineered' code.

So this leads me to two points.  The first is that the 'ilities' 
associated with software engineering are meant to help people
cope with the problems they have had/still do have/will continue to have
with modifying code when some 'baseline' is reached.  This applies
to code sizes small, medium, and large.  Now there are things in
software engineering, like object-oriented design, data flow analysis,
etc., that help people reach the initial baseline they are striving for.
If done properly, not only will this 'software engineering' help them
make changes to this baseline, it should also help them, or some poor 
lost soul who has the misfortune of picking up this baseline from
someone else, figure out what they were doing when they reached this 
baseline.  In my example above, the EE ran into problems several times
because of his design/lack thereof.  Was this due to inexperience??
Maybe, but as time went on, I think he wished he had done some of
the 'software engineering techniques' that he knew about, but ignored.

My second point deals with my reference to 'software artists', rather
than 'software engineer'.  If you apply the 'software engineering
techniques', one will find the strengths and weaknesses in doing so.
But the knowledge base that one will obtain will allow them to
tackle the next software assignment with more 'colors on their palette.'
If one only knows about red, green, and blue (do loops, if-then-else,
assignment statements) a picture can indeed be painted, and 'beauty
will be in the eye of the beholder.'  If one has more colors, a different
picture can be painted.  But I will bet you the person that had the
red, green, and blue will try and logically explain why there 'picture'
is better, as will an argument come from the painter with more colors.
Neither side will listen to the other, and each artist will be 
resistent to the other side.  So to conclude, I like 'software
engineering techniques' because I like trying new ways to solve
problems, and every time I apply them, I learn something new.
It is very hard to argue with someone who has painted their picture
with red, green, and blue, maybe painfully mixed some of the colors to 
get green, yellow, magenta, cyan, black, and white, and they are
'proud' of their picture.  To tell them otherwise is 'insulting to
them.'

Allen Adams