Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!swrinde!emory!mephisto!mcnc!duke!romeo!crm
From: crm@romeo.cs.duke.edu (Charlie Martin)
Newsgroups: comp.software-eng
Subject: Re: Theory vs. Practice in CS Education
Message-ID: <16270@duke.cs.duke.edu>
Date: 30 Nov 89 20:24:38 GMT
References: <5072@ae.sei.cmu.edu> <16185@duke.cs.duke.edu> <5132@ae.sei.cmu.edu>
Sender: news@duke.cs.duke.edu
Reply-To: crm@romeo.UUCP (Charlie Martin)
Organization: Duke University CS Dept.; Durham, NC
Lines: 218

In article <5132@ae.sei.cmu.edu> rsd@sei.cmu.edu (Richard S D'Ippolito) writes:
>
>Charlie, you start off OK, but include sarcastic remarks later in your
>article.  I will try to close most of this discussion down:
>
I was trying to be pointed without being personally offensive, so please
accept my apologies for anything you took personally.  This is first
draft stuff and tone-of-voice is hard to get across.

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

Agreed one hundred percent!

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

Wow, about 17 good questions here.  Let's see:

I think it is true that the "machining" of software engineering is and
always will be "programming," and as with Brooks's No Silver Bullet
paper, I am suspicious that the process that leads to the final
realization of the system will always be complex and always will require
substantial detailed effort.

I don't think it is true that all programming is or will be software
engineering; in fact, my opinion of the future of programming is that
"languages" very specific to very limited domains -- like spreadsheets
-- will eventually replace general programming with user-defined and
user-modified specifications that happen to be efficiently executable.
Once we grow past very limited programming domains, I think we begin to
hit very basic softs of computation-theoretic and cognitive limits,
which in turn I think account for Brooks's NSB phenomenon.

The reason there are good MEs who are not machinists I think is that
there are good machinists who aren't ME's.  The skills really are
different, but a good machinist has no reason to feel ashamed of their
skills.  (And good tool and die makers usually make as much or more than
even the most experienced engineers in that kind of environment.)

As far as whether it will always be true that we must teach programming
to teach software engineering, I don't know.  On the one hand, by
analogy it seems not; on the other hand, unlike a mechanical engineer,
we run into Church's Thesis in software engineering: a mechanical
engineer can manipulate drawings and strenth-of-matericals rules and
ODEs without manipulating the basic materials; on the other hand,
anything that we manipulate that describes a computation is in itself a
kind of or model of computation.

So my *guess* is "no, but someday we'll have better programming
notations that will make programming better and/or more intuitive."  The
formal methods work that I have been doing recently seems to me to be
aimed in that direction, but there is a long long way to go.  I don't
even have a hint of what the end product will be like.

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

I mean instead to suggest that some large part of what we allocate to SE
ought to be part of CS, thereby leaving us alone to figure out things
like what the problems of scale are, and find solutions.  

The kind of "good" I'm thinking of is in part aesthetic (dammit) and so,
no, I suspect we can't measure it.  But I think we'd agree on the
generalities: few non-standard transfers of control, layout of the code
on the page that emphasizes important parts of the code structure,
modularity and design that raises the probability that a change will
require minimal changes  (information hiding, paramterization, etc.)

These kinds of things seem to scale badly; conversely, there are a
number of things that seem important only after size > 10^4 SLOC.  One
reason that I suspect the "code hygiene" stuff is not "software
engineering" is that I think it is important on a much lower scale than
the other topics of SE are.

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

I think we've reached a point of arguing where the optimal trade-point
is, itself an engineering decision.  But every engineer needs to deal
with "build or buy" unless dealing with nearly trivial problems.

>
>>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'm not an ME, but that's not my impression from talking to MEs.
(I don't recall, did you say you were?  May have been someone else.)  In
any case, my father in law is a mechanical engineer, and tells the story
of needing a bearing, designing it, and then having his supervisor point
out that he could have had one from the parts catalogue over his
drafting board.

Again, I think we've worked down to the point of considering where the
optimal point of a trade off lies.  A person who specializes in
designing bearings will necessarily know more about properties and
current art than someone who just needs one that doesn't show in the
catalogue; if the ebaring will be a safety-critical component, then it
is probably the correct engineering decision to hire a consultant or
find an expert in the company.  On the other hand, even I don't need an
expert to tell me how to design a poured-babbitt bearing to replace the
bearing in my ancient lawnmower that can't be purchased any longer.  (I
can look it up with a little effort, and the result is not critical in
any meaningful way.)

>
>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...
>
Actually, given your comments I think there is an interesting question
here: are techniques for writing (maintaining) 1000-10,000 SLOC
programs part of software engineering vs. being part of computer
science?

My opinion (as I said) is that they ought not be; on the other hand, I
feel constrained to accept what appears to be the common definition, at
least without making an explcit argument for my own.  

I'm sorry, but I just munged the remaining stuff from you, so I'll
paraphrase rather than recovering it.  (Stupid vi....)

In any case, the last part of your message first suggested that the
basics of operating systems, file structures etc wouldn't be any use
while designing your first MCCR system.  The acronym isn't familiar to
me; tell me what it is and I'll tell you if I believe it.  I find it
unlikely, since I find it hard to imagine a program that doesn't use
*one* of the basics of any of the topics I mentioned as seeming
essential.  But I can't argue on that basis.

The last issue is the question of what a software engineer needs or
doesn't need to know.  My expectation with reference to this was based
on current techniques and current art, not based on the assumption that
*someday* people will be able to software engineer without knowing how
to program, and I think it's still a valid question.

The way I understood your response before I mashed it was essentially
that the topics of a course in operating systems are not useful for
software engineering, but that it was a motherhood statement that people
ought to know everythig about everything; that it was unnecessary to
know anything in particular about designing the physical carriage for a
large antenna if you're designing the RF paths.

But what this comes down to is the assertion that designing an operating
system is "a different kind of" software engineering than designing
these MCCR systems, for example.  But this implies that MCCR system
designers need to know something as different from what operating systems
designers need as Young's modulus is different from cavity resonance.
In other words, it seems to assert that MCCR designers don't need to
know about operating systems design because they aren't designing
operating systems.

Since this is a paraphrase, I can't assert that it is circular
reasoning, but my recollection of it sure seems to be.  I don't accept
the axiom that operating systems are that difference; I think there is
good reason to assert that they are not, and that they in fact
(a) illustrate good SE principles, and (b) are good things to know about
in terms of the core knowledge a software engineer needs.

So far, it *seems* that I and others have offered a number of reasons
for this; the counterargument seems to be that operating systems courses
teach things that aren't needed for people who build something else.

All of this presumes that every operating systems course is presumed
equal, which isn't fair.  On the other hand, all the OS courses I've
taken, and all the OS books I've read, illustrate (more or less well)
much more general concepts about design of large or time-critical or
performance-critical systems that I think very SE needs.

So I'd still like to know: what was in YOUR OS course that shouldn't
have been?  If so, is it essential to a concepts of OS course in the
sense that an OS course wouldn't be recognizable as an OS course without
it?  Or was it an accident of that particular text, that particular
instructor, or the tools the instructor had with which to teach labs?
Charlie Martin (crm@cs.duke.edu,mcnc!duke!crm) 


Brought to you by Super Global Mega Corp .com