Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!nrl-cmf!mailrus!tut.cis.ohio-state.edu!bloom-beacon!mit-eddie!uw-beaver!cornell!rochester!ur-tut!msir_ltd
From: msir_ltd@ur-tut (Mark Sirota)
Newsgroups: comp.software-eng
Subject: Re: Cynic's Guide to SE, part 2
Message-ID: <1396@ur-tut.UUCP>
Date: 18 Mar 88 05:27:02 GMT
References: <2586@Shasta.STANFORD.EDU>
Reply-To: msir_ltd@tut.cc.rochester.edu (Mark Sirota)
Organization: Univ. of Rochester, Computing Center
Lines: 65
Distribution:


In article <2586@Shasta.STANFORD.EDU> neff@Shasta.UUCP (Randy Neff) writes:
> One of the serious flaws in Software Engineering is there is no standard
> methodology for determining that one software program or methodology is 
> "better" than another.
>
> This is unlike other engineering fields; say electrical engineering.  There
> a audio power amplifier can be judged by its cost, power output, distortion,
> frequency response, crossover, phase delay, power in, heat disipated, and
> weight.   These are all numeric quantities that most EEs can measure; 
> there are no subjective biases or opinions expressed.  Together, the 
> values form an absolute "goodness" based on electrical engineering practice.
>
> In constrast, in the software arena, we have feature lists, platitudes,
> grandious claims that result in giant flame wars with all of the rationale of
> religious dogma and persecution.

Possibly you've just picked a poor example, but then again the entire
premise may be flawed.  It is completely incorrect to say that audio power
amplifiers can be judged - there is as much religion to it as software.
(If you don't believe me, try fighting your way through rec.audio, or ask
any two audiophiles which amplifier on the market today is best).

Sure, you can measure all those qualities of amplifiers, but determining
what's best from the data is magic.  It's one of the hottest controversies
in the audio kingdom today.  The problem is not in the measurement, it's
in the interpretation of the data.

>  [ "suggestion" about X in ADA deleted ]
> Now the point of this article is not the answer to this particular question,
> but to show that one of the failing of software engineering is there is no
> rational basis for answering that sort of question.

Not only is there no rational basis for answering it, there's no rational
basis for asking it.  There is simply no way to say that a Lincoln is
better than a Porsche (or vice-versa) because they don't cater to the same
market.  Although both will get you from point A to point B, the Lincoln
is actually better than the Porsche for some tasks.  Likewise, C is better
than Lisp for some things, and Lisp is better than C for others.

Your proposed system of measures would have an awful lot to take into
account - there are an awful lot of differing intents and purposes out
there.

> I have been involved in religious wars about text editors, and about
> operating systems, and programming languages.  And they all seem to boil
> down to "I like this and you're wrong!".

What that answer is really trying to say is that "I like this FOR THIS
PURPOSE and you're wrong!"  I'm as guilty of it as anyone - just try to
get me to use another editor.  Because another part of the problem is what
you're used to - I like EMACS-style editors, because I know how to use
them very well.  Why should I learn another editor for this task, when I
can get along with what I already know?  (I know the answer to this, so no
flames - it's a tradeoff, just like everything else.)

> there should be an software engineering methodology to determine what is
> the "best" program for the job.  ... Once such a methodology was in place,
> then it could guide the incremental improvement of those programs.

You said it yourself - FOR THE JOB.  To develo such a methodology, you'd
first have to quantify the job, and that's no easier than doing the
measurements.
-- 

Mark Sirota
 msir_ltd%tut.cc.rochester.edu@cs.rochester.edu (rochester!ur-tut!msir_ltd)