Re: Software Engineering is not a hoax...

[kaz@vision.crest.nt.com (Kaz Kylheku)]

In article <338B2118.41C67EA6@metaware.com>,
Scott Stanchfield  <scotts@metaware.com> wrote:

>> I am pretty sure that in 15 years from now, a programmer looking at code will
>> immediatly complain if the module is not following the principles of OO or is
>> not designed as an Abstract Data Type.
>
>I'd say this is more akin to "using acceptable grammar" than applying
>engineering techniques.

I'd say that it's more, because the technique has a definite impact on the
verifiablity and maintainability of the program. Abstract data types and OO
are more than just mere terms. I would agree with that they aren't
_engineering_ techniques.

>Think about "Ugh! Me Kronk" versus "Hello, my name is Scott."  Did I
>engineer that sentence?  I applied grammatical rules, but I wouldn't say
>that it was engineered.

I see what you are getting at. Since a program is an utterance in a programming
language, it's not a product of engineering but of abstract symbol
manipulation. Good point!

>The problem I have with the notion of Software "Engineering" is when
>people say software development is just like building cars.
>That's just a plain bad analogy.  Think about car production.  Cars do
>one thing -- transport.  Sure, some can be more fun than others, some
>may be better at towing, some may carry more people, but they are all
>basically the same.  The parts used to make them are basically the same.

But we can have reusable components. Different models of car are similar in the
same kinds of ways as two different red-black tree implementations.  Their
parts are not interchangeable, yet they are basically the same.

I would not go as far as saying that there are no useful similarities between
engineering and software development, or that some of the rigorous techniques
in engineering can be applied to software, in particular, the technique of
formal verification. In engineering, designs are verified. For example, a truss
will undergo analysis in which the tensile or compressive stresses in each
member are determined under given load conditions. Nobody will build the bridge
without having done such an analysis. To apply this principle of verification
to software, every component of a software project should be formally verified
for correctness. 

>Car production is basically doing the same thing over and over and over
>and over.  Things get a bit better and specialized sometimes, but it's
>still building something to do the same task.
>
>I've never written more than one program to do exactly the same task
>(unless I'm rewriting it to improve it.)  Each time I sit down to code
>something the goal is different.  This, in turn, implies the combination
>of parts needed to construct it, and the order in which those parts are
>put together is different. (These "parts" I refer to are language
>constructs, known algorithms and simple reusable objects like
>containers.  Nothing too big, or you're getting into doing the same task
>again.) 
>
>Sure, we can use common algorithms and objects such as containers and
>math packages.  But the overall product is not something that has been
>done before, and therefore, there is no proven, repeatable method to
>"engineer" that work.

Then again, many engineering designs are also unique. Think of unique
structures in the world: dams, buildings, bridges and so on.  There are proven,
repeatable ways to locally verify the designs, one component at a time.
E.g. there are methods to analyze any truss network to see whether it will
hold up, but you can still be very creative in designing the truss.
In engineering, the creativity is checked by applying laws derived
from natural science. <insert some Robert Pirsig quote here about motorcycle
gears having buddha nature :) >