[comp.software-eng] Is it Art or is it Engineering

csm@garnet.berkeley.edu (Brad Sherman) (02/06/88)

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?

Is there anything in programming that is analogous to
the term "tolerance" in engineering?


	Brad Sherman - (You See Bee)

I don't know what I like, but I know art when I see it.

apte@duke.cs.duke.edu (jitendra apte) (02/07/88)

In article <6879@agate.BERKELEY.EDU> bks@ALFA.berkeley.edu (Brad Sherman) writes
>
>Is there anything in programming that is analogous to
>the term "tolerance" in engineering?
>

how about the following :

designing and writing programs that are expected to yield acceptable results
most of the time, but not guaranteeing good results for all possible inputs.
a typical attitude while  writing programs to solve problems which are known
to have very time consuming exact solutions, but which can probably be solved
to near exctness using heuristic methods. (np problems and the more expensive
p problems).

jitendra apte.

geoff@desint.UUCP (Geoff Kuenning) (02/07/88)

In article <6879@agate.BERKELEY.EDU> bks@ALFA.berkeley.edu (Brad Sherman)
writes:

> Is there anything in programming that is analogous to
> the term "tolerance" in engineering?

It seems to me that heuristics are analogous.
-- 
	Geoff Kuenning   geoff@ITcorp.com   {uunet,trwrb}!desint!geoff

kent@xanth.cs.odu.edu (Kent Paul Dolan) (02/07/88)

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?

Real engineers build bridges that work when delivered.

>Is there anything in programming that is analogous to
>the term "tolerance" in engineering?

If by tolerance you mean the kind you measure with micrometers, sure.
That is what all those convergance criteria are in numerical analysis.

If you mean the twelvefold over strength needed wooden beams in some old
houses, then again yes.  We do it when each routine checks its inputs,
even when they are created within another subroutine of the same
program, when we check the return code on the "close()" file command
in C, which is folk rumored never to fail, but has actually been known
to do so.  We call it paranoia!  ;-)

>
>	Brad Sherman - (You See Bee)
>
>I don't know what I like, but I know art when I see it.


Kent, the man from xanth.

svb@teddy.UUCP (Stephen V. Boyle) (02/08/88)

In article <6879@agate.BERKELEY.EDU> bks@ALFA.berkeley.edu (Brad Sherman) writes:
>current software development is not really "engineering."
>
>What do "real" engineers do that we do not?
>

Since my background is Chemical Engineering, I'll use examples from that field.

In Chem. E., when I needed to design a heat exchanger, I used a set of refer-
ences that told me what the constants were for the materials the heat exchanger
was going to operate on, and the *standard* design equations for the exchanger
itself. I don't mean to imply that every problem in Chem. engineering (or any 
other engineering) design is easily and completely reduced to "look up the
numbers", but it sure happens a heck of a lot more than when I'm writing soft-
ware. 

Sure, there are some examples of "canned" routines and algorithms (quicksort
is what immediately comes to mind), but in general, unless I, or someone else
in my engineering group has read or remembers and makes known a solution to a 
past problem, I'm doomed to re-create the solution.  The closest thing I can
think of to what I consider "real" engineering in software are the user-
interface building tools that let you quickly design a screen layout and which
then generate the corresponding code.  I guess what I consider the critical 
difference is the ability to put together little pieces of the problem that are
relatively well known, without having to generate a custom solution for every 
application. This would allow software people to spend time on what makes the 
current application unique.

Now before people get their keyboards cranked up, I want to make it clear that
I am aware of algorithm and code libraries, but they are incomplete solutions
to what I am describing. (There is no "Perry's Handbook" for Software Engineer-
ing.) Plus, none of the above even whispers about scheduling. I'm not going to 
get into that tar pit, I've depressed myself enough for a Monday morning.

-- 
... !{decvax,linus,wjh12,mit-eddie,masscomp}!genrad!svb
Steve Boyle  
GenRad Inc,  Production Test Division
MS 06, 300 Baker Ave, Concord, Mass.  01742

mac3n@babbage.acc.virginia.edu (Alex Colvin) (02/08/88)

> >What do "real" engineers do that we do not?
> 
> Real engineers build bridges that work when delivered.

Real engineers rearely attempt to convert a ferry boat into a bridge.
Software engineers do it all the time.

hollombe@ttidca.TTI.COM (The Polymath) (02/09/88)

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.

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

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.

-- 
The Polymath (aka: Jerry Hollombe, hollombe@TTI.COM)   Illegitimati Nil
Citicorp(+)TTI                                           Carborundum
3100 Ocean Park Blvd.   (213) 452-9191, x2483
Santa Monica, CA  90405 {csun|philabs|psivax|trwrb}!ttidca!hollombe

decot@hpisod2.HP.COM (Dave Decot) (02/09/88)

I agree that the distinguishing characteristic between what this
"industry" does and engineering is the general unexpectation that what
is produced will perform exactly as specified.

I think independent software validation organizations could make pots
full of money if they became well-known and reliable.  Something like
UL (Underwriters' Laboratories) for software.

Dave Decot
hpda!decot

ok@quintus.UUCP (Richard A. O'Keefe) (02/09/88)

In article <4618@teddy.UUCP>, svb@teddy.UUCP (Stephen V. Boyle) writes:
> Sure, there are some examples of "canned" routines and algorithms (quicksort
> is what immediately comes to mind)

Oh dear, I do hope not.  Everybody seems to be hypnotised by the NAME
"quicksort".  If you check a good reference (Knuth AofP, for example)
you'll find that quicksort is ***not*** a good general-purpose sort!
For a generic sort (comparison is a caller-supplied function, not a
single machine instruction selected at compile-time, or is string
comparison) merge-sort beats quick-sort handsomely.

svb@teddy.UUCP (Stephen V. Boyle) (02/10/88)

In article <691@unm-la.UUCP> claborn@unm-la.UUCP (Joe Claborn) writes:
>... deleted discussion of what constitutes a "best solution" ...
>
>The best software to a solve a specific problem may be a piece of 'canned'
>software or it may be developed 'in-house'. In either case if there
>is not engineering involved in the decision then the solution won't be
>'best'. 

I agree with your criteria. My point was that things which are well-defined are
not saved and re-used *in the general case*.  All engineering, including the
example I used of heat exchanger design, involves original work.  It may be
that more or fewer parameters or "building blocks" may be available, but sooner
or later it comes down to the engineer doing their part.  If there was no new
engineering to be done, then the customer would (should) have bought an off-
the-shelf solution.  My point was that not many software building blocks exist,
except for relatively trivial functions, which is part of the reason I feel 
that software engineering today is more art than engineering.

In article <635@cresswell.quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes:
>In article <4618@teddy.UUCP>, svb@teddy.UUCP (Stephen V. Boyle) writes:
>> Sure, there are some examples of "canned" routines and algorithms (quicksort
>> is what immediately comes to mind)
>
>Oh dear, I do hope not.  Everybody seems to be hypnotised by the NAME
>"quicksort".  If you check a good reference (Knuth AofP, for example)
>you'll find that quicksort is ***not*** a good general-purpose sort!

Agreed. The statement was intended to reference a common, relatively well-
known case, without making any value judgements about its use or suitability.

So, how can software development become more like engineering? Beats me. At 
this point all I have is vague uncertainties and "sort of - kind of" thoughts
about what could be done different. But I think the comparisons with more
"traditional" engineering disciplines can display some interesting parallels, 
along with divergences, regarding engineering practice.

-- 
... !{decvax,linus,wjh12,mit-eddie,masscomp}!genrad!svb
Steve Boyle  
GenRad Inc,  Production Test Division
MS 06, 300 Baker Ave, Concord, Mass.  01742

csm@garnet.berkeley.edu (02/10/88)

Do programmers, in general, work under greater time pressure than real
engineers?

Are there objective metrics by which real engineers have their productivity
judged?

Is it easier to tell an amateur mechanical engineer from a professional
m.e. than it is to tell an amateur C programmer from a professional?

	     - Brad Sherman
(Perhaps more importantly, who makes more money and why?)

UH2@PSUVM.BITNET (Lee Sailer) (02/11/88)

In article <4620@teddy.UUCP>, svb@teddy.UUCP (Stephen V. Boyle) says:
>So, how can software development become more like engineering? Beats me. At
>this point all I have is vague uncertainties and "sort of - kind of" thoughts
>about what could be done different. But I think the comparisons with more
>"traditional" engineering disciplines can display some interesting parallels,
>along with divergences, regarding engineering practice.
     
I have always wondered why there are so few software "handbooks" to go
along with all the engineering handbooks.  There are lots and lots
of little "standard" components in any big program, for example:
     
o sort list in memory with good average time performance
     
o sort external file with good worst case performance
     
o find the first line in a file that satisfies P.
     
o find all lines that satisfy P.
     
o merge two lists.
     
o merge k lists
     
o maintain a priorty queue
     
o parse a regular expression
     
o match a contextr free pattern.
     
etc etc etc.
     
   Sure, there are a lot of them, but there are a lot of IC's, too.
There are good ways to do all these things, and they could be described
in a general way in psuedo-code, or in specific languages, or whatever.
     
They would have to be categorized in some way to make it easy to find
the one you need when you need it.
     
Knuth almost satisfies this description, except that it should be called
the Handbook of Software Technique, and should be demystified (i.e.
use a friendlier notation) so that most programmers could use it.
     
Voila--engineering!  8-)
     
                        lee
     

pase@ogcvax.UUCP (Douglas M. Pase) (02/11/88)

In article <hpisod2.16520001> decot@hpisod2.HP.COM (Dave Decot) writes:
>I agree that the distinguishing characteristic between what this
>"industry" does and engineering is the general unexpectation that what
>is produced will perform exactly as specified.
                                  ^^ ^^^^^^^^^

There's the rub.  If we had a notation sufficiently precise to completely
specify what our programs were supposed to do, we would use this specification
language as a programming language, write a compiler, and then they would
perform exactly as specified.  Denotational semantics has been pushed in that
direction (if I'm not mistaken).  In a sense, the programming language is a
specification of the program behavior -- if it doesn't work right, it's because
the programmer didn't specify the behaviors correctly.

This, by the way, is a favorable argument for using higher-level languages
(functional, logic, etc.) when it is possible to do so, and teaching people
how to use them without introducing "impurities" into their code.  If used
correctly, they could boost code reliability, and certainly our understanding
of common problems.  Code verification for "pure" functional/logic programs
is far easier than for imperative languages, to the point of being relatively
trivial.  Implementations of such languages are becoming efficient to the point
of rivaling imperative languages, so efficiency is no longer a problem.  They
are not yet widely available, nor is there a large programming force that
could use them if they were.  Maybe that will come later.
--
Doug Pase  --  ...ucbvax!tektronix!ogcvax!pase  or  pase@cse.ogc.edu (CSNet)

warren@ihlpf.ATT.COM (Montgomery) (02/11/88)

The question of whether software art or software engineering more
correctly describes what software people do is age old.  While
software development has aspects of both to it, I'd like to suggest
that the dominant aspect for any large project is neither, it's
management of complexity.

In large systems, there are tasks that are clearly engineering. 
Picking data structures and algorithms to achieve a desired level of
fault tolerance is one that comes to mind, as is figuring out how to
cope with widely varying loads with acceptible performance.  

The enterprise that to me most clearly models a software development
is that of publishing a large multi-author document, such as a
newspaper, a magazine, or an encyclopaedia.  There is a large part
of the input that is creative in nature, both in determining overall
structure and in filling in the sections.  There are also many
specialized sub-problems, such as page layout, printing, production
of figures, obtaining the rights to material taken from other
sources, etc.  A lousy product will be produced if the basic
creative talent of the people who must supply it isn't up to the
task.  The best printing and layout in the world won't sell a
newspaper with poor writers.  Assuming that this is taken care of,
though, the dominant concern is managing the thousands of individual
tasks involved so that they come together when required to make a
product.

-- 

Warren Montgomery ihlpf!warren

noise@eneevax.UUCP (Johnson Noise) (02/13/88)

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.

daveb@geac.UUCP (David Collier-Brown) (02/14/88)

In article <32637UH2@PSUVM> UH2@PSUVM.BITNET (Lee Sailer) writes:
>I have always wondered why there are so few software "handbooks" to go
>along with all the engineering handbooks.  There are lots and lots
>of little "standard" components in any big program, for example:
>     
>o sort list in memory with good average time performance
>     
  Well, I've seen about two:
Rodgers, David F., "Procedural Elements for Computer Graphics", New
York (McGraw-Hill) 1985.

... and I lent my Hopity-and-somebody data structures book out, so I
can't give a citation for it.

  Rare, but not unknown.

-- 
 David Collier-Brown.                 {mnetor yunexus utgpu}!geac!daveb
 Geac Computers International Inc.,   |  Computer Science loses its
 350 Steelcase Road,Markham, Ontario, |  memory (if not its mind) 
 CANADA, L3R 1B3 (416) 475-0525 x3279 |  every 6 months.

noise@eneevax.UUCP (Johnson Noise) (02/14/88)

In article <3676@ihlpf.ATT.COM> warren@ihlpf.ATT.COM (Montgomery) writes:
>The question of whether software art or software engineering more
>correctly describes what software people do is age old.  While
>software development has aspects of both to it, I'd like to suggest
>that the dominant aspect for any large project is neither, it's
>management of complexity.
>
	I think you hit the <proverb-op1> right on the <proverb-op2>.

>In large systems, there are tasks that are clearly engineering. 
>Picking data structures and algorithms to achieve a desired level of
>fault tolerance is one that comes to mind, as is figuring out how to
>cope with widely varying loads with acceptible performance.  
>

	When people talk about complexity of a project, I give the
following example:

Unix distribution exec. size: > 30 Mbytes
Unix distribution source size: ~ 3 million lines (no comments)
Average programmer productivity: < 10 lines/programmer-working day

Total project size: ~ 1,200 programmer-years.

Clearly a big project.

>sources, etc.  A lousy product will be produced if the basic
>creative talent of the people who must supply it isn't up to the
>task.  The best printing and layout in the world won't sell a
>newspaper with poor writers.  Assuming that this is taken care of,
>though, the dominant concern is managing the thousands of individual
>tasks involved so that they come together when required to make a
>product.
>

	I'm glad to find at least one person who thinks clearly about
these things.

UH2@PSUVM.BITNET (Lee Sailer) (02/15/88)

In article <1553@ogcvax.UUCP>, pase@ogcvax.UUCP (Douglas M. Pase) says:
>
>In article <hpisod2.16520001> decot@hpisod2.HP.COM (Dave Decot) writes:
>>I agree that the distinguishing characteristic between what this
>>"industry" does and engineering is the general unexpectation that what
>>is produced will perform exactly as specified.
>                                  ^^ ^^^^^^^^^
>
>There's the rub.  If we had a notation sufficiently precise to completely
>specify what our programs were supposed to do, we would use this specification
>language as a programming language, write a compiler, and then they would
>perform exactly as specified.  Denotational semantics has been pushed in that
     
Yes, but...
     
A specification language would specify exactly *what* was to be done,
but not necessarily *how*.  E.g., "...ans sort the file in less than
5 seconds..." is a specification, but not a compilable program.
     
Of course, languages like Prolog are moving that way...
     
                                                       lee
     

joe@nsc.nsc.com (Joe Caporaletti) (02/20/88)

Virtually every engineering displine of the industrial revolution
relies on the analytical concept of functional decomposition.  A system
is decomposed into processes with well defined input/output effects
on other processes.  This partitioning is the basic technique for
handling complexity by allowing each processes to be understood
separately.

Software is distinguished from other engineering disciplines by
the necessity to specify algorithms as a SEQUENCE of simple
one word operations.  This is necessary since there is only one
central processing unit which can operate on the data in memory.

Functional decomposition is used in software as an analytical tool
(e.g. data flow diagrams).  However, efficient implementation requires 
sequencing of operations.  Therefore, the functionality is transformed 
to a sequenctial algorithm.  There is no simple set of rules for doing this.
Although there has been a lot of good research on program proving,
there is yet no practical formalism for showing that a particular sequencing
of operations is functionally correct.

The complexity and unprovable nature of the of the transformation from 
functionality to sequential algorithmic implementation is unique to software.
For example, although a hardware designer has many options for the 
implementation of some particular combinatorial logic function, the 
engineer must use standard mathematical techniques (e.g. Boolean Algebra) 
to prove that the choosen implementation matches the desired functionality.
While software walk-throughs are a great idea, they are really a 
hand-waving substitute for a formal proof.

In other engineering disciplines like mechanical or chemical engineering,
a great deal of research goes into proving the reliability and
repeatability of the basic processes and principles on which they rely.
When software can apply the same kind of research to everyday problems, it
too will be an engineering discipline.  This is probably several years off
and will require a sophisticated degree of automated assistance to the
process of program transformation.

Knuth knew exactly what he was doing when he named his series "The Art of
Computer Programming."


Joe Caporaletti
Software Engineering and Tools Specialist
National Semiconductor

terry@wsccs.UUCP (terry) (03/02/88)

In article <4618@teddy.UUCP>, svb@teddy.UUCP (Stephen V. Boyle) writes:
> I am aware of algorithm and code libraries, but they are incomplete solutions
> to what I am describing. (There is no "Perry's Handbook" for Software
> Engineering.)

	What about Knuth?


				- terry@wsccs