Xref: utzoo comp.edu:2684 comp.software-eng:2453
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!uakari.primate.wisc.edu!xanth!mcnc!duke!romeo!crm
From: crm@romeo.cs.duke.edu (Charlie Martin)
Newsgroups: comp.edu,comp.software-eng
Subject: Re: CS education
Message-ID: <16109@duke.cs.duke.edu>
Date: 16 Nov 89 17:23:55 GMT
References: <16028@duke.cs.duke.edu> <7023@hubcap.clemson.edu>
Sender: news@duke.cs.duke.edu
Reply-To: crm@romeo.UUCP (Charlie Martin)
Organization: Duke University CS Dept.; Durham, NC
Lines: 93

Oh good, I was beginning to think that this article hadn't gotten
out....

In article <7023@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes:
>From crm@romeo.cs.duke.edu (Charlie Martin):
>> There is also a lot of software engineering that has little or nothing
>> whatsoever to do with computer science, and which I think belongs in a
>> business school: things like life-cycle models, management metrics, etc.
>> These are NOT the things which computer science or even traditional
>> engineering deals with; they are much more like the quantitative methods
>> that an MBA uses.
>
>   Business schools exist to produce *non-technical* managers,
>   and are unlikely to be interested in changing, even if it
>   were appropriate (which I rather strongly doubt).  Technical
>   management would be one of the things that would migrate away
>   from CS into a software engineering department, which IMHO is 
>   its proper position within the academic structure. 
>

Um, exactly which business school are you talking about, Bill?
Stanford, Duke, are both schools that I am aware make a heavy emphasis
on quantative modelling of the things managers manage.  That is,
people, schedules, risks, costs ... all the things (plus some others)
that seem to come into software engineering from the management
direction.  I'm not disputing that these things are important: there's
a discussion of some of these issues in my dissertation, and I have
several publications on them.  Many schools now offer emphasis on
technical management, and even back in the early pliesteocene when I
was an undergrad, U of Colorado offered a program where one could get a
BSE and an MBA in five years, because of the perceived need.  

>Operating systems is not a field which contains
>real-time programming; if anything, it's the other way around.
>Obviously  scheduler operation is an important consideration in
>certain types of programming, but does this imply that one should
>train to BUILD schedulers or to USE them?   Obviously, the latter.

It's less than obvious to me for two reasons: (1) how can you explain
the operation of the scheduler without discussing the operation of the
scheduling algorithms in detail, which implies at least some pseudocde;
(2) how can you (teaching software engineering) discuss the
implementatino of programs like a scheduler without working with
something much like a scheduler code?

>> The techniques that come from learning to write compilers also are
>> useful to solve a large variety of real-world problems even if you
>> can't spend your time writing compilers.

> The point is not that the time would be totally wasted, but that the
> time would be much better spent concentrating on software engineering
> or application problem solving rather than on systems programming.

Maybe the question that ought to be asked here is just what is software
engineering?  From your arguments, I might plausibly come to the
conclusion that it isn't implementing operating systems, compilers, or
programs that construct string-to-string transformations.  It is
real-time programming but not schedulers, resource lists, resource
allocation tables, memory management or any of those operating systems
things.  It doesn't seem to be -- for example -- the primitive scheduler
I wrote once for a real-time hardware control program; it doesn't seem
to be choice of appropriate algorithms for performance-critical
programs, since that requires an understanding of analysis of
algorithms; it does seem to be by your arguments life cycle models and
PERT charts, which are hardly specific to software.

Are you sure you aren't talking about industrial engineering or
technical project management?  What is the specificity to computers?

Realize that in some ways I'm on *your* side: we are taking people and
giving them computer science degrees, in the full knowledge that they
will be working two weeks later as "software engineers" and that 95
percent of them wiull never come back for a CS advanced degree.  We
aren't teaching them, often, even the basics, like why you comment a
code or how to test one.  If we're lucky, they may have picked up a lot
of that in labs, but they may also have been instructed by people who
believe that more than one phrase of comments per function is foolish
superfluity, and who have never written a significant code realizing a
complex specification in their lives.  We don't give them much in the
way of instruction in the things that really are specific to the
engineering professions, like choosing among design options, optimizing
to meet many conflicting goals, and design to reduce cost of
construction.

Someday I'd like to see many of the computer science courses be to
software engineering majors what the calculus/linear algebra/diffEQ
sequence is to other engineers.  But I find it just as hard to imagine
that we will be able to do without operating systems or compiler
construction as I would to imagine a mechanical engineer could do
without a strength of materials course.


Charlie Martin (crm@cs.duke.edu,mcnc!duke!crm)