Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!pt.cs.cmu.edu!sei!rsd
From: rsd@sei.cmu.edu (Richard S D'Ippolito)
Newsgroups: comp.software-eng
Subject: Re: Theory vs. Practice in CS Education
Message-ID: <5132@ae.sei.cmu.edu>
Date: 29 Nov 89 19:18:22 GMT
References: <5072@ae.sei.cmu.edu> <16185@duke.cs.duke.edu>
Reply-To: rsd@sei.cmu.edu (Richard S D'Ippolito)
Organization: Software Engineering Institute, Pittsburgh, PA
Lines: 142


Charlie, you start off OK, but include sarcastic remarks later in your
article.  I will try to close most of this discussion down:


In article <16185@duke.cs.duke.edu> Charlie Martin writes:
>In article <5072@ae.sei.cmu.edu> Richard S D'Ippolito writes:
>>In article <16169@duke.cs.duke.edu> crm@romeo.UUCP (Charlie Martin) writes:
>>
>But you've got a major point here that I think needs serious
>consideration: the designer is not yet separate from the carpenter in
>software.  It's like the mechanical engineer being the machinist or
>toolmaker.
>
>The opposite side of this is that while mechanical engineers don't need
>to be machinists, mechanical engineers need to understand machine tools
>and manufacturing operations.  

Agreed -- but it's not the opposite side.  Process knowledge is always
necessary in order to be an effective engineer.


>The other side of this is that we can't TEACH software engineering
>without requiring the students become machinists; there's not much you
>can teach about programming without teaching programming.

Here is where we might part.  I agree with the second clause, but am not
sure about the first, which seems to imply that the mechanics of software
engineering is programming.  If this is true now, will it always be?  And
why are there good mechanical engineers who are not machinists, good EEs who
couldn't design and lay out an IC, etc.?


>The solution in my opinion is that we have to make sure that part of
>teaching computer science is teaching the low-level skills that have
>been considered part of software engineering up to now.  I don't think
>any computer science grad ought to be able to graduate without
>understanding how to write a good program at the 1000--10,000 SLOC
>level.  

Here you seem to have equated CS with SE.  Is there no difference?  What
does it mean to have a 'good' program?  Can we measure that?  Will it scale
up to 1,000,000 SLOC?


>...But when an engineer designs a bearing that is needed, which is not
>in the parts catalogues from the acceptable suppliers, but which is
>within the common state of art, he is not doing science: there is no
>hypothesis/experiment cycle going on.  

An EE can buy some resistance wire and wind his own resistors, but he would
try like heck to avoid that and wouldn't consider marketing the results.
Consider the technology that he would have to know in order to guarantee the
performance of them.  There would be a great deal of science and
experimentation involved.  In fact, my view of a good systems EE was one who
knew better than to design his own switching-regulator power supplies.  


>Similarly, all engineered software is created from known models (check
>e.g. the plans work of Soloway) and most other algorithms are designed
>on the basis of existing models as well.

You are down at a very low component level, here, what we consider to be
implementation.  Systems engineers try to stay out of it.  


>In designing a bearing, a designer had better know about the properties
>of other bearings, and of the materials that make them up.  

Right, but isn't this a speciality generally out of the reach of the average
mechanical engineer?


>>>I don't think anyone is under the impression that you are learning
>>>engineering when learning about finite state automata and the executable
>>>models of them.  
>>
>>This is true for you, but not for those who suggested (and still insist)
>>here that courses in OS and compilers were good ways to learn software
>>engineering.
>>
>I *am* glad that we have your infinite knowledge to draw on, Richard.

Please, let's not trade gratituitous comments.  Your next statement shows
you knew exactly what I meant:


>That is ever so much clearer now.  Funny, I had thought that the others
>were mostly arguing that OS etc courses were a good place to *present
>examples* of software engineering and its problems.  But being a mere
>mortal, I can only draw on what I read, not on my intimate knowledge of
>what other people know.

OK, here is what they said:

    In article <7036@hubcap.clemson.edu> A. Jeff Offutt writes:

    >Here's one of my ideas for a perfect software engineering project:
    >   An operating system. ...Another one: A compiler

Notice that he did NOT say computer science project.

    In article <4251@pegasus.ATT.COM> Paul S. R. Chisholm writes:

    >What good are compiler courses?  Well, when writing code I want to run
    >fast, I always feel more comfortable when I know more or less what the
    >compiler is going to turn my code *into*; and the only way I can do
    >that is at least read about compiler implementation techniques.
 
Notice that he is writing code, i.e., doing implementation and not design.

Drawing on what I read and just presented, I will stand by my analysis of
the intent.  Let's just disagree on our readings of the above...


>I'm not wedded to the *names* of the courses; call them Larry Moe and
>Curly for all that I care.  But many of the theory topics presented must
>(in my opinion) be reinforced with realistic examples, and courses like
>compilers, operating systems, and oh, data base courses are a convenient
>place to do this. 

Not one of those will prepare you for emgineering your first MCCR system,
believe me!  Good luck!


>So I don't know -- what doesn't the list include?  What do you think is
>*not* appropriate for a software engineer to know?
>Charlie Martin (crm@cs.duke.edu,mcnc!duke!crm) 

Well, the last question has the appearance of, but not the unassailability
of Motherhood.  EEs who specialize in radar design do NOT have all of the
scientific knowledge (beyond principles of E&M) necessary to design heavy
rotating machines.  There is a fundamental gap between being able to
understand (even intimately) how an operating system works and how to
engineer one.

Rich
-- 
When you can measure what you are speaking about, and express it in numbers,
you know something about it.
Lord Kelvin						      rsd@sei.cmu.edu
-----------------------------------------------------------------------------


Brought to you by Super Global Mega Corp .com