Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!pt.cs.cmu.edu!sei!bwb
From: bwb@sei.cmu.edu (Bruce Benson)
Newsgroups: comp.software-eng
Subject: Re: CASE - The Emperor has no clothes on!
Message-ID: <7527@fy.sei.cmu.edu>
Date: 13 Jun 90 21:14:38 GMT
References: <7486@fy.sei.cmu.edu> <1990Jun13.101122.15604@axion.bt.co.uk>
Reply-To: bwb@sei.cmu.edu (Bruce Benson)
Organization: Software Engineering Institute, Pittsburgh, PA
Lines: 75

In article <1990Jun13.101122.15604@axion.bt.co.uk> pyoung@zaphod.axion.bt.co.uk writes:
>From article <7486@fy.sei.cmu.edu>, by bwb@sei.cmu.edu (Bruce Benson):
>> How much has bridge building changed since the first bridge was built? Sure
>> the techniques and materials have changed dramatically, but a bridge of
>> today would still be recognized by a builder of centuries past.  The same
>> for buildings.  
>This is not intended as a personal assault on Bruce Benson, but I

Not to worry ;-).

>can't help wondering if building bridges is an appropriate analogy for
>what we are doing.

The point I was trying to illustrate is that our intuitive concept of
engineering comes from such mundane, *mastered* efforts such as building
a bridge.  We are confident when we plan to build a bridge that the bridge
will work.  We are looking for that same type of confidence when we plan to
build something with software.  *Engineering* is the word and reference
that may be inappropriate since it brings so much baggage in meaning from
the traditional disciplines. 

We want to be as confident as a bridge builder, but we are not building
bridges.  We don't rebuild the same word processor over and over again.
Instead we upgrade or build *new or novel* capabilities with each new word
processor.

>required properties of a database are as well known as the properties
>for a bridge. The bridge designer is able to follow a set of rules to
>prove that his design satisfies the required properties. This is the
>point where traditional engineering and software engineering diverges.

Putting it another way, don't we see domain specific technology
(database in particular) becoming available that moves us away from having
to *prove that his design satisfies* or maybe reducing drastically what
has to be proven in creating the object (bridge or database)?  Mundane
databases are being created using dBase or Informix instead of C or
Pascal.  The house builder uses 2 by 4s not 3 by 5s to build with.  More
importantly the builder uses *standard* *enabling* processes and
technology to build with.  The standard problems (databases) in a given
context (personal computers) we have *solved* to our current level of
expertise.

>Until we have developed methods of calculating programs from
>specifications (and this day is not as remote as you might think!) we
>are not an engineering discipline in the traditional sense.

Won't moving the *programming* up a Level (levels?) of abstraction only
move the problems up to a higher level?  Agreed, this is where we are
going, and have gone (machine code->assembler->HOL->4GL->CASE), and is
what we are striving to do in the SE field.  But if the conjecture that
we always push our limits is valid, won't the same SE problems
manifest in the activity of specification?  Can a specification language
capture and characterize *human* creative ideas any better than machine
code?  

>What I am trying to say is that where the problem is well-defined, we
>should be in a position to derive a set of rules specific to the
>problem. That way engineering principles could be introduced in
>certain cases without having to wait for general purpose solutions to
>be developed.

I would suspect that if a problem is well defined and has a space of well
defined solutions, we probably have done this.  Can you illustrate?

The two central questions were:
  1.  Are we not mastering software engineering a lot more than we admit?
  2.  Are we not confusing bad-results-from-pushing-the-outer-limit with
      mastery-of-software-engineering-in-things-we-know?

Bruce

* Bruce Benson                   + Internet  - bwb@sei.cmu.edu +       +
* Software Engineering Institute + Compuserv - 76226,3407      +    >--|>
* Carnegie Mellon University     + Voice     - 412 268 8496    +       +
* Pittsburgh PA 15213-3890       +                             +  US Air Force