MDAY@XX.LCS.MIT.EDU (Moderator, Mark S. Day) (02/22/88)
Soft-Eng Digest Sun, 21 Jan 88 Volume 4 : Issue 9
Today's Topics:
Free Ugrades & Bug Fixes
Help Explain the Concepts of the Future
Int'l Neural Network Society Meeting
Job Position Ad for SoulWaste (Humor)
Is it Art or Engineering? (10 msgs)
----------------------------------------------------------------------
Date: Thu, 11 Feb 88 14:44:27 PST
From: PAAAAAR%CALSTATE.BITNET@cunyvm.cuny.edu
Subject: Free Ugrades & Bug Fixes
A long while ago and a long way from California I had two colleagues who
worked as Consultants and Programmers for a Computer Manufacturer who wanted
what we now call a Wide Area Network put in for a special customer.
THey were (and still are I guess) highly competent producers of software
but this was before the term 'Software Engineering' was in use.
They designed, coded, and tested the network - all was well and handed it over
to the manufacturer who then called a meeting with the customer to wind up the
project. The manufacturer included the following phrase in the final contract:
" ...complete except some small improvements to made by ...."
My colleagues exploded at the insult.
The manufacturer explained that they had *never* sold any software that had
not had bugs and that the phrase was the standard escape clause they used
to cover themselves for when "The door falls off the Washing Machine".
My colleagues forced the manufacturer to remove the phrase.
As far as I know the network continued running, bug-free, until it was
replaced.
Conclusion - Good non-trivial software is not impossible,
but nobody will believe until they see it.
Dick Botting
PAAAAAR@CCS.CSUSCC.CALSTATE(doc-dick)
paaaaar@calstate.bitnet
PAAAAAR%CALSTATE.BITNET@{depends on the phase of the moon}
Dept Comp Sci., CSUSB, 5500 State Univ Pkway, San Bernardino CA 92407
voice:714-887-7368 modem:714-887-7365 -- Silicon Mountain
Disclaimer: The content of this message has been massaged by much software
and probably does not say what I wrote anyway.
------------------------------
Date: Fri, 12 Feb 88 07:38:08 -0500
From: G B Reilly <reilly@UDEL.EDU>
Subject: Help Explain the Concepts of the Future
The Franklin Institute Science Museum* will be opening
the Futures Center in 1990. This is not a copy of EPCOT
Center or a futuristic living room. It is exhibits to
explain the new concepts in science and technology that will
affect people's lives in the coming years.
One section explains the concepts of robotics, computing,
and artificial intelligence. We are interested in hearing
what you believe the public needs to know about these areas
and how they will affect their life in the next decade.
Thank you for your cooperation.
Brendan Reilly
Curator
----
* The Franklin Institute is one of the oldest science museums
in the country and has hands-on exhibits explaining science
and technology which are visited by over one million people annually.
------------------------------
Date: Wed, 10 Feb 88 18:05:26 EST
From: mike%bucasb.bu.edu@bu-it.BU.EDU (Michael Cohen)
Subject: Int'l Neural Network Society Meeting
INNS 88 UPDATE AND CALL FOR PAPERS
International Neural Network Society
First Annual Meeting
September 6--10, 1988
Boston, Massachusetts
The International Neural Network Society (INNS) invites all
those interested in the exciting and rapidly expanding field of
neural networks to attend its 1988 Annual Meeting. Incorporated
in 1987, INNS already includes among its members 1300 of the field's
most active researchers and is growing rapidly. The meeting
includes plenary lectures, symposia, contributed oral and poster
presentations, tutorials, commercial and publishing exhibits,
government agency presentations, and social events. These events will
bring together scientists, engineers, government administrators, industrial
administrators, and students in an open form for advancing the full
spectrum of significant neural network research from biology through
technology.
JOIN US IN BOSTON IN SEPTEMBER!
COOPERATING SOCIETIES:
The Societies listed below have generously agreed to cooperate with the INNS
meeting.
American Mathematical Society
Association for Behavior Analysis
Cognitive Science Society
Computer Society of the IEEE
IEEE Control Systems Society
IEEE Engineering in Medicine and Biology Society
IEEE Systems, Man and Cybernetics Society
Optical Society of America
Society for Industrial and Applied Mathematics
Society for Mathematical Biology
Society of Photo-Optical Instrumentation Engineers
Society for the Experimental Analysis of Behavior
[ For more information contact: ]
INNS Conference
16776 Bernardo Center Drive
Suite 110B
San Diego, CA 92128 USA
(619) 451-3752
------------------------------
Date: 2 Feb 88 03:43:43 GMT
From: jperry @ unix.SRI.COM
Subject: Job Position Ad for SoulWaste (Humor)
[Taken from job newsgroup by moriarty@allegra.UUCP (Jeff Meyer)]
Join the dynamic team here at SoulWaste. We want people who
believe in the hi-tech religion and who are willing to work 60 hour
weeks under florescent lights in grey buildings with windows that
don't open. After all, the earth will stop rotating on its axis
if our product doesn't get out the door before the competition.
You must be a mindless zealot who's idea of a good time is
playing MacIntosh computer games on nights and weekends and who's
conversations with other people sound like a Wang commercial.
You must believe in the Yuppie vision of the world as shown in
Wang, H-P, and AT&T commercials where people are shown thinking
about their job while swimming or walking their dog and where
everybody is inadequate if they haven't purchased the latest
wiz-bang box or felt anxious guilt if their office system isn't
networked to everything more hi-tech than a Smith-Corona typewriter.
Yes, we don't just want your hours at SoulWaste -- we want
your soul!!
Qualifications: Must be willing to sacrifice any semblance of
real life for carrots held at the end of sticks
i.e. BIG BUCKS.
Must have huge repertoire of computer buzzwords
in vocabulary.
Must feel the same degree of mania as company
management when products are late getting out
the door.
Must have no social life -- 'cause we're gonna
fatigue you so much you ain't gonna have one
anyway.
Oh, yeah, must know the C programming language.
Direct inquiries to this dynamic and growing conspiracy, I mean, er,
company to:
Simon LeGree
Telephone: 1-800-FAUSTUS
------------------------------
Date: 9 Feb 88 01:21:49 GMT
From: beta!unm-la!claborn@nyu.edu (Joe Claborn)
Subject: Is it Art or Engineering?
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?
I thought that engineering was choosing the best solution (given constraints)
from the solution space. Perhaps that when designing heat exchangers the
engineering is ALREADY done and can be looked up in a table. For a lot of
software that isn't the case. I define best solution as the solution that
minimizes the following costs.
--> cost of implementing
--> cost of maintenance
--> cost of modifying
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'.
------------------------------
Date: 8 Feb 88 22:03:28 GMT
From: ctnews!pyramid!prls!philabs!ttidca!hollombe@unix.sri.com (The Polymath)
Subject: Is it Art or Engineering?
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
------------------------------
Date: 8 Feb 88 15:56:04 GMT
From: uvaarpa!virginia!babbage!mac3n@mcnc.org (Alex Colvin)
Subject: Is it Art or Engineering?
> >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.
------------------------------
Date: 9 Feb 88 19:59:27 GMT
From: panda!teddy!svb@husc6.harvard.edu (Stephen V. Boyle)
Subject: Is it Art or Engineering?
In article <691@unm-la.UUCP> claborn@unm-la.UUCP (Joe Claborn) writes:
>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
------------------------------
Date: 10 Feb 88 05:41:09 GMT
From: agate!garnet.berkeley.edu!csm@ucbvax.Berkeley.EDU
Subject: Is it Art or Engineering?
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?)
------------------------------
Date: 9 Feb 88 19:03:56 GMT
From: trwrb!aero!venera.isi.edu!raveling@ucbvax.Berkeley.EDU (Paul Raveling)
Subject: Is it Art or Engineering?
There's a heavy component of art in much software development,
sometimes for better, sometimes for worse. This is especially
true for developing software without a well-defined (detailed)
functional specification. Some examples from my own experience...
EPOS (PDP-11 operating system, ISI, 1975++),
GenRad/FutureData Slave Emulator product line, 1969++
Perhaps 50% art and inspiration, 50%
production by engineering discipline.
B1-B Central Air Data Computer, Standard Central
Air Data Computer, ~1984
99% engineering discipline
It seems to me that the most innovative work of lasting
value involves a lot of art. However, not many people
can say "Fund me; I'll create a masterpiece!" and be
taken seriously.
Paul Raveling
Raveling@vaxa.isi.edu
------------------------------
Date: Thu, 11 Feb 88 12:44:57 PST
From: Eugene Miya <eugene@ames-nas.arpa>
Subject: Is it Art or Engineering?
>There seems to be a perception among programmers that
>current software development is not really "engineering."
Try going around a while and use the word CRAFT. CRAFTSMAN, CRAFTSWOMAN,
CRAFTSPERSON....
>What do "real" engineers do that we do not?
Over engineer tolerance into systems ;-).
>Date: 7 Feb 88 02:51:53 GMT
>From: xanth!kent@mcnc.org (Kent Paul Dolan)
>
>Real engineers build bridges that work when delivered.
Not all the time. ;-)
>If by tolerance you mean the kind you measure with micrometers, sure.
>That is what all those convergance criteria are in numerical analysis.
Too bad. I wish more people would consider this, they rarely do.
--eugene miya
------------------------------
Date: 12 Feb 88 01:42:41 GMT
From: rochester!ritcv!mjl@bbn.com (Mike Lutz)
Subject: Is it Art or Engineering?
Anyone who has worked with a really good electrical or mechanical engineer
knows that there is every bit as much room for creativity, elegance, and
art in those domains as in software development. However, it does seem that
one can make a decent living as an E.E. by remembering a bunch of formulas
from Circuits III (or, better yet, the page in the CRC reference books where
the formulas can be found). The current state of software development is such
that such canned solutions are rare, so an even higher premium must be placed
on native design talent.
Good God! I said something nice about hardware types!
Mike Lutz
Rochester Institute of Technology
rochester!ritcv!mjl
--
Mike Lutz Rochester Institute of Technology, Rochester NY
UUCP: {allegra,seismo}!rochester!ritcv!mjl
CSNET: mjl%rit@csnet-relay.ARPA
------------------------------
Date: 10 Feb 88 18:42:43 GMT
From: uh2@psuvm.bitnet (Lee Sailer)
Subject: Is it Art or Engineering?
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
[ Speaking of Knuth, his 1974 Turing Award address was on the subject
of art vs. science, and explained why he called his handbooks
"The Art of Computer Programming". I highly recommend it and the
other Turing Award addresses. The lectures of the first 20 years
were recently collected into a book, published by the ACM Press.
--MSD ]
------------------------------
Date: 10 Feb 88 19:25:45 GMT
From: tektronix!reed!percival!littlei!ogcvax!pase@ucbvax.Berkeley.EDU (Douglas M. Pase)
Subject: Is it Art or Engineering?
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)
[ A clear and well-reasoned discussion of the good and bad points of
functional programming is "Real Programming in Functional Languages"
by James H. Morris, Xerox PARC report CSL-81-11. The abstract is:
"The established properties of functional languages -- easy to define
semantics and mathematical elegance -- are appealing to
meta-programmers who study programming and programs at one remove.
Most people believe that functional programming is inappropriate for
real programmers who write programs that are judged on their
behavior rather than their appearance. We shall explore this
question by considering experience with two languages, Poplar and
Euclid, that have a claim to being functional languages and to being
used on real problems -- string processing and system programming,
respectively."
I don't know if this was published in a more readily-available form than this
tech report. --MSD ]
------------------------------
End of Soft-Eng Digest
******************************
-------