Re: Software Engineering is not a hoax...

[Scott Stanchfield <scotts@metaware.com>]

Kaz Kylheku wrote:
> 
> In article <338B2118.41C67EA6@metaware.com>,
> Scott Stanchfield  <scotts@metaware.com> wrote:
> 
> 
> >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!
Thank you!

> 
> >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.

Guess my point got missed here.
In cars, common parts are assembled in pretty much the same manner for
any given car.  Testing a car is similar from car to car.
Same domain for each "overall" test.  (Car testers -- please do not be
offended -- I'm not saying your job is simple...)

(How did we move into testing?)

In programming, each new program presents a different domain.  In order
to test, you have to think in that domain and create new tests within
it.  Sure, there are similarities, but no "checklist" that says what
things to think of when testing a car.

(I also believe it has been proven that program correctness is, in
general, unprovable.  There are simple subsets that can be proven
correct, but as program size grows, the probability of proving
correctness diminishes.)



[snip re I don't write the same thing twice]
> 
> 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 :) >
Again, unsure how we got into testing, but...
From what I recall of my Naval-Architect roomie's ramblings on
structural analysis, I think it's somehow related to physics ;)
Science vs. art, and ya know where I stand...

Anyway, certain parts of programs can be tested with common program
testing techniques, just as certain parts of programs implement common
algorithms and data structures.  But, I think that developing the proper
test for a propgram is just as unique as writing the program to begin
with.  It's a matter of figuring out the right combinations of common
tests and new tests to get the "warm fuzzies" or, better still, complete
confidence in the correct operation of a program.  (In that respect,
verification of design of some structures is a creative process as
well.)  Think about geometric theorem proving.  You have a set of
"knowns" and an "unknown."  You have to think out the correct
combination of "knowns" to prove your unknown.  No engineering technique
can tell you how to combine them, though you can learn useful patters
that can help get the job done.

(This is the most intellgent discussion of this topic that I've heard in
a while -- very interesting...)
-- Scott


-- 
Scott Stanchfield
MetaWare Incorporated
Santa Cruz, CA
(The opinions expressed herein are not necessarily those of MetaWare)