Xref: utzoo comp.edu:2659 comp.software-eng:2404
Path: utzoo!attcan!sobmips!uunet!cs.utexas.edu!tut.cis.ohio-state.edu!pt.cs.cmu.edu!sei!rsd
From: rsd@sei.cmu.edu (Richard S D'Ippolito)
Newsgroups: comp.edu,comp.software-eng
Subject: Re: CS education
Message-ID: <4969@ae.sei.cmu.edu>
Date: 16 Nov 89 16:38:32 GMT
References: <9759@june.cs.washington.edu> <34740@regenmeister.uucp>
Reply-To: rsd@sei.cmu.edu (Richard S D'Ippolito)
Organization: Software Engineering Institute, Pittsburgh, PA
Lines: 79


The following article of Chris Parel makes many excellent points, which I
would like to emphasize:

   In article <34740@regenmeister.uucp> Chris Prael writes:

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

Right!


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

=The engineering model is superficially similar but quite different in
=fact...
=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.  

This is right on the mark!  From Tomas Maldonado, "The Aspen Papers":

    "Therefore we must say that for the moment the most distinctive
    characteristic of man is not his capactiy to solve problems but
    more his capacity to set them."


=...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 analyze, 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 aesthetic appeal,
=in cost, and in timeliness.
=
=Chris Prael

Excellent!  D. Schoen, in "The Reflective Practicioner", concludes:

    I have become convinced that universities are not devoted to the
    production and distribution of fundamental knowledge in general.
    They are institutions committed to the most part to a particular
    epstimology, a view of knowledge that fosters selective inattention
    to practical competence and professional artistry. ... By 1967
    engineering design had virtually disappeared from ciricula and the
    question of the relationship between art (problem framing) and
    science (problem solving) was dead.

Happily, a few institutions now require courses in engineering design at the
undergraduate and graduate levels.  However, I have yet to see these kinds
of courses required for computer science students, at any level.


Rich

-- 
We use kill ratios to measure how the war is going.
We use SLOC ratios to measure how our software is coming.
(Idea from Gary Seath)                                        rsd@sei.cmu.edu
-----------------------------------------------------------------------------