Xref: utzoo comp.edu:2618 comp.software-eng:2329
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!seismo!sundc!newstop!sun!sunfedcomm!regenmeister!chrisp
From: chrisp@regenmeister.uucp (Chris Prael)
Newsgroups: comp.edu,comp.software-eng
Subject: Re: CS education
Message-ID: <34740@regenmeister.uucp>
Date: 10 Nov 89 22:21:27 GMT
References: <9759@june.cs.washington.edu>
Sender: daemon@sunfedcomm
Organization: Sun Microsystems, Inc. - Mtn View, CA
Lines: 85

From article <9759@june.cs.washington.edu>, by peterd@cs.washington.edu (Peter C. Damron):
> In article <34705@regenmeister.uucp> chrisp@regenmeister.uucp (Chris Prael) writes:
>>There is a basic set of disciplines to engineering.  This set seems to
>>be well taught in civil and mechanical engineering curricula and less
>>well in electronic engineering curricula.  The set seems to be taught
>>little or not at all in the typical computer science curriculum.
 
> I'm not sure I know what you are talking about.
> Just what is this "basic set of disciplines" that engineers learn?
> How does it differ from what I would call "tools and techniques"?

Nor am I particularly sure of what you mean by "tools and techniques", I
made an assumption based on fairly extensive experience and observation.
If you don't mind, I will include a bit of your subsequent posting in
this.

> I "hear" a lot of
> "talk" about the need for more software engineering, but little about
> what people mean by software engineering.

One must first recognize that an item of software is an artifact.  A C 
compiler is just as much an artifact as is a suspension bridge, an
automobile, or a stereo receiver.  It is not functional to differentiate 
these artifacts by the degree of concreteness or abstraction.  The main
points are that each of these artifacts has a use or range of uses, that 
each was designed and built by someone, and that each performs well when 
it is applied appropriately.

There are two basic styles, or paradigms, of the process of designing
and building: the technician model and the engineer model.  We have all
seen plenty of examples of both models at work.  

The technician model depends mainly on rote.  Typically, a technician
examines a problem until a match is found to a previous experience.  The 
previous experience is then replicated concretely, possibly with minor 
variations.  If the technician reaches a point at which the assumed
match fails, he may undo some or all of his work to that point.  He
would then start another search for a matching experience to try.  

Names for this model in various environments are "cut and try",
"blacksmithing", and "prototyping".  It is effective when applied to
very small projects.  We all use it around the house to fix the car or
patch the roof.  It is not particularly effective when the project is
large enough to involve more people.

The engineering model is superficially similar but quite different in
fact.  One must first recognize that engineering is a social act.
Unless a project is very trivial, the activities of (often large)
numbers of people must be co-ordinated.  An engineer with poor
communication skills is a functonal cripple.

Often, the engineer's objective is initially vaguely defined.  So, the 
first discipline of an engineer is the patience to research and analize 
an issue with the object of isolating a solvable problem.  

The next phase is global (or external, or functional) design.  Designing 
is superficially similar to the technician's cutting and trying, but it 
is done mainly or entirely in the head.  The engineer's focus, in this
phase, is satisfying the requirements that were given or developed in
the previous phase.  Implementation details are largely ignored.

The third phase is the design of the implementation, also called
internal design or detail design.  

Only after each of these phases has been performed and the results 
reviewed and revised and re-reviewed, does the engineer start the actual
implementation.  The implementation phase is the one in which the "tools
and techniques" are used.

Obviously, the effectiveness of the definition and design phases are is 
affected by breadth or narrowness of the engineer's experience of "tools 
and techniques".  So, it is reasonable to say that a broad exposure to 
"tools and techniques" is a necessary condition in the training of an 
engineer in a specific field.  But, it is equally clear that the exposure 
is not even remotely sufficient.

A student in computing who is only exposed to "tools and techniques"
without being taught to analize, design, and review has been equipped
only to function as a technician, not as an engineer.

The differences between the product of an engineer and that of a
technician are grossly apparent in effectiveness, in easthetic appeal,
in cost, and in timeliness.

Chris Prael