From: jgd@dixie.com (John De Armond)
Subject: Re: Software as PE
Date: Sat, 02 Jan 93 00:10:35 GMT
Organization: Dixie Communications Public Access.  The Mouth of the South.
Distribution: na

marc@tanda.isis.org (Marc Thibault) writes:

>        Fred J asked me to define a real engineer. Here's my shot at

Very excellent analysis.  Couple of additional thoughts.


>        Software development methods are anything but time-tested;
>        they are changing as we speak and none has been consistently
>        successful at turning out software that is both reliable and
>        efficient. The (relatively) rare program that meets those
>        criteria is inevitably the result of intensive hacking by a
>        master craftsman whose respect for the paradigm-du-jour would
>        be infinitesimal if he or she cared what it was. Nor is the
>        behavior of the components well understood. That's why we have
>        bugs while engineers make design errors. We can't engineer
>        software because we haven't yet figured out _how_. Calling
>        programmers software engineers is at best wishful thinking,
>        and wishing only makes it so in Disneyland.

I don't believe software creation will ever become an engineering 
discipline any more than the creation of oil paintings will.
Both are inextricably linked to the craftsman's artistic intellect.

I'm one of those people who is educated in a conventional engineering
discipline and got into software after about 15 years of conventional
practice.  I was able to watch the evolution of my brand of engineering
(nuclear instrumentation) move from the sliderule era through the 
calculator and into the computer age.  At the same time I am a (budding)
artist, working with hot glass.  I can therefore observe both sides.

Consider a few things.  First, languages.  It is intrinsicly difficult to
move between programming languages.  Some people are gifted in this
area, of course, but for most people, learning a new programming language
is quite a chore.  That is because each language embodies a different
way of approaching the creative process.  Assembler programmers tend
to do things quite differently than SQL programmers.  This is at odds with
the conventional engineering disciplines where the same methodologies
are used throughout.  I found little difficulty, for example, on 
picking up on designing hydraulic systems.  A little bit of reading
and some study to find out what the standards were and away I went.

Consider artistic media, on the other hand.  An oil painting artist does
NOT easily move into, say, stained glass.  A wood carver cannot easily
become a painter.  This is quite in parallel with programming.  While
a central artistic ability has to be present in both cases, one's skill set
may only match certain media.  I personally have tried for years to find
a media in which to express some of my artistic ideas.  Hot glass appears
to be it.  I tried drawing and cartooning and painting and sucked bilgewater
at them all.  Woodcrafts are not much better.  Yet I find working with
glass easy and people tell me my work is quite good.

Same with software.  As a development manager, I've found most programmers 
excel in one or two areas.  I have little patience with end-users and 
therefore do poorly with applications.  Communications, on the other hand,
seemed a natural.  

>        I don't think this is forever. Wide adoption of standard
>        objects will, in time, give the craft of programming a leg up
>        on the way to engineering. 

I don't much think so.  I suspect it will further the development of a
technician/craftsman class of programmers analogous to the carpenter
or electrician.  These people will bolt together variations of standardized
applications just as carpenters hammer togethers pretty standard structures
from "objects" of wood (the plank.)  In this niche may be the place for
the licensed engineer to oversee the design of these things when the end
result has public safety implications.

This brings up another difference between engineers and software development.
Most any engineered system can be proved correct or else the weaknesses
can be comprehensively identified.  Provably correct designs have
been a big thing in the nuclear biz for the last 20 years or so.  It is
this concept that has kept computers out of the reactor control and 
protection loop until recently and even then, the impossibility of provably 
correct software systems is addressed by massively redundant systems AND 
by keeping the human operator in the loop.

>        No electronic engineer has ever advertised himself as expert
>        only with the "Apex Model 5 Logic Analyser". Anyone who
>        studied to be an electrical engineer with me can, in
>        addition to engineering electrical systems, design a logic
>        circuit or machine tool, program any computer, build a barn or
>        a cannon, distinguish between a terminal moraine and a
>        land-fill site, survey a meadow, and navigate a ship.

Yup, and that is in stark contrast with many "CS" programs that 
seldom venture out to anything outside the computer.

I think the titles "science" and "engineering" get tagged onto what 
programmers because a) academians realize the engineering schools get
all the money and thus want the same legitimacy as, say, the school
of nuclear engineering, b) because corporate managers realize the same
thing applies in business and c) upper management could not stand the
idea of paying big bucks to a bunch of people who are identified as
artists.

John
-- 
John De Armond, WD4OQC               |Interested in high performance mobility?  
Performance Engineering Magazine(TM) | Interested in high tech and computers? 
Marietta, Ga                         | Send ur snail-mail address to 
jgd@dixie.com                        | perform@dixie.com for a free sample mag
Need Usenet public Access in Atlanta?  Write Me for info on Dixie.com.
Newsgroups: comp.org.eff.talk,alt.amateur-comp,soc.culture.usa,alt.activism