Path: utzoo!utgpu!water!watmath!clyde!bellcore!decvax!purdue!umd5!eneevax!noise
From: noise@eneevax.UUCP (Johnson Noise)
Newsgroups: comp.software-eng
Subject: Re: Is it Art or is it Engineering
Summary: Art or Engineering
Keywords: Art Engineering Tolerances
Message-ID: <1230@eneevax.UUCP>
Date: 13 Feb 88 01:42:20 GMT
References: <6879@agate.BERKELEY.EDU> <1879@ttidca.TTI.COM>
Reply-To: noise@eneevax.umd.edu.UUCP (Johnson Noise)
Organization: Elec. Eng. Dept., U of Maryland, College Park, MD 20742
Lines: 54

In article <1879@ttidca.TTI.COM> hollombe@ttidcb.tti.com (The Polymath) writes:
>In article <6879@agate.BERKELEY.EDU> bks@ALFA.berkeley.edu (Brad Sherman) writes:
>>There seems to be a perception among programmers that
>>current software development is not really "engineering."
>>
>>What do "real" engineers do that we do not?
>
>Engineers typically work with known quantities and predictable results.
>What they're doing has usually been done before and is well understood.
>(e.g.:  We've built a lot of office buildings.  We know how long it takes
>to put up girders and floors and wiring.  There are tables of beam sizes
>and riveting codes, etc.).  That's why PERT charts work so well with
>engineering projects.
>

	I think you are quite wrong.  There are many types of buildings
that have not been designed or built (e.g. sufficient structure to with-
stand natural forces etc.), but what do I know? I'm an electrical clown
myself.

>
>Software designers/builders, on the other hand, are usually doing something
>that hasn't been done before.  If it had been, why do it again?  Why not
>just copy it?  (It's a bit difficult to copy an office building (-: ).
>
	Uh, no.  Think about the algorithms that are commonly used in
most programs. I think you will find that most of the ideas were
conceived 20-30 years ago.  I am not suggesting that new techniques are
not discovered or "designed", but think about it.

>Software is a more creative, seat-of-the-pants endeavor than "hard"
>engineering.  There are no tables of beam strengths or fluid flows to
>refer to.  There are standard references for limited types of algorithms
>and these generally are copied rather than built from scratch.  But the
>reason for any new software project is to make a computer do something it
>hasn't done before.  There are many unknowns in such an undertaking, which
>is why the PERT model doesn't fit software development very well.  There's
>still some art to it.
>
	I think you should spend a little more time on the other end of
your RS-232 cable before making such a statement.  I am an electrical
engineer, but I have been programming for almost as long.  I try to look
at both worlds and I think that there not enough poeple with open minds.
Philosophy about man-machine interaction is useful, but a machine is still
a machine, and man is not.
	There has been change. In machines it is mostly speed, not concepts.
In programs, mostly nomenclature.  We are not programmers any more, we
software engineers.  Fortran, LISP, SNOBOL, Unix, they are all very important
milestones, but not of this generation.  What more has been accomplished
through the change of names?  Not nearly as much.  We should focus more on
what to do, how to do it, and not the labels.
	Art is subjective, and that can't be changed.  A friend of mine is
making the final fixes to a 500MW pulsed power modulator.  He designed it,
built it, and will sign it like any artist would.