From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_20 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,bf72ca9e8a6b3cf
X-Google-Attributes: gid103376,public
From: Richard D Riehle <laoXhai@ix.netcom.com>
Subject: Re: Software Engineering in Florida
Date: 1999/11/08
Message-ID: <8075f4$t1q$1@nntp3.atl.mindspring.net>
X-Deja-AN: 546008832
References: <1e0rgtb.6j187t1hibcsaN@[209.132.126.64]>
 <7vv26t$tju$1@nnrp1.deja.com> <lpdV3.8$C%6.715@typhoon.nyu.edu>
 <804plo$dvs$1@nntp5.atl.mindspring.net> <807202$9if$1@nnrp1.deja.com>
Organization: MindSpring Enterprises
X-Server-Date: 8 Nov 1999 18:40:36 GMT
Newsgroups: comp.lang.ada
Date: 1999-11-08T18:40:36+00:00
List-Id: <comp.lang.ada>

In article <807202$9if$1@nnrp1.deja.com>,
	Robert Dewar <robert_dewar@my-deja.com> wrote:

>In article <804plo$dvs$1@nntp5.atl.mindspring.net>,
>  Richard D Riehle <laoXhai@ix.netcom.com> wrote:
>> Is software engineering simply an attractive oxymoron?
>
>I assume you mean contradiction in terms (I see no possible
>interesting literary effect in this particular phrase :-)

I have, indeed, used it in its defined sense of "a combination
of contradictory words or terms.  However, since you mention 
literary effect, I am suddenly intrigued by the possibilities. :-)

>I disagree, engineering has nothing to do with the state of
>development of a discipline, but rather with the *kind* of
>discipline. It is clear to me that the activities of building
>software are fundamentally similar to other engineering
>activities.

I always love it when you disagree with me.  Your positions are
always intelligently considered and intellectually challenging.

As to the state of the discipline, when I was a young man growing
up in farm country, we would manufacture temporary tools using
baling wire and other materials at hand.  One could call that
engineering, but most farmers would simply call it "making do."
A huge body of the work that passes for software engineering
product reminds me of the baling wire implements from the farm.
Someone once described software as a "pile of dry rot held up by
a flying buttress."   At some point, the state of the craft does
evolve from baling wire art to engineering.  The place where it
makes its transition is a function of the level of rigor we apply.
That rigor, in engineering, includes a well-known body of design
metrics.  While we have made some progress in design metrics in
software practice, there is a very long way to go before we can
achieve the level already in place for physical engineering.

In an earlier post I mentioned "industrial engineering."  It was a
long time before physical engineers acknowledged the validity of this
branch of engineering.  Many still refuse to take it seriously.  Our
field, software, would probably learn something valuable from the
evolution of industrial engineering to its current place in the
realm of engineering.  

In the physical world we carefully differentiate between architects
and engineers.  We also distinguish between a carpenter and an architect,
a metal worker and an engineer.   With all of the discipline required
for creating a working computer program, and such discipline is
essential as we know from experience, the effort is not that of
engineering.  It is closer to that of an inventor, experimenting with
some interesting ideas until something works.  

I do not want to oversimplify the engineering process.  Many engineering
projects are also characterized by trial and error.  For example, no
one knew that fluting an aluminum would increase its compression
strength by 20 percent.  Once the mathematical properties of fluting 
were studied, we had a model for predictability for other materials.
Such predictability is rare in software practice.  Most programmers
don't even recall the properties of Big O computations.  The use of
metrics in design is practically non-existent.  

I respectfully submit that the state of the practice is an important
criterion for determining whether software development is an engineering
discipline or simply another craft.

>Well to many people programming means coding, so that is in
>fact a useful term, to emphasize that coding is just one
>aspect of the total engineering effort.

Yes.  A draftsperson is someone who renders an engineering design
into a format that can be studied by engineers and builders. The
manufacturing people must be able to interpret the drawing.  But
no one, especially the draftsperson, would call that draftsperson
an engineer.   When we take to calling an Oracle database programmer
an engineer, we are trivializing the term and proving a point
to those who reject software practice as an engineering discipline.

This is why I am saying that we must take care in our use of the term
engineering when referring to software practice.  We need a solid
definition of software engineering, in the context of conventional
engineering, that makes sense.  Pressman, in his widely-used book 
on software engineering goes on for pages and pages before he ever
defines software engineer, and then the definition is not very good.
Sommerville also falls short in this.  If the textbooks we use for
teaching software engineering are unable to define software engineering
in the context of general engineering practice, how can we expect to
be regarded as credible by our brethren in other engineering fields.

><We tout Ada as a software engineering language>
>
>I hope not, this is a useless idea, almost as useless as
>object oriented programming language :-)

Well, you know we agree on this.  Where did I put that left-handed
monkey-wrench, anyway?   :-)

>Languages are tools in which you can do many things. Calling
>a programming language a software engineering language is
>like calling a hammer a "fine furniture building hammer" :-)

Of course, there are many different kinds of hammers.  We do have
tack hammers, ball peen hammers, claw hammers, and, my personal
favorite, the sledge hammer.  I see a programming language as closer
to being a tool box.  A good tool box will have the tools I need 
for solving problems.  I will never forget one of my great lessons
in metrics as a young man working on an automobile engine.  I should
have used a torque wrench and didn't.  The recommende torque for a
particular set of bolts was published.  Like any good programmer,
I simply twisted the top off and drilled out the bolt buried inside
the engine block.  Why would I have wanted to rely on the published
metrics since I could always fix it later?
 
Richard Riehle