Xref: utzoo comp.edu:2685 comp.software-eng:2454
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: <16110@duke.cs.duke.edu>
Date: 16 Nov 89 17:50:02 GMT
References: <16028@duke.cs.duke.edu> <7024@hubcap.clemson.edu>
Sender: news@duke.cs.duke.edu
Reply-To: crm@romeo.UUCP (Charlie Martin)
Organization: Duke University CS Dept.; Durham, NC
Lines: 69

In article <7024@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes:
>From crm@romeo.cs.duke.edu (Charlie Martin):
>    ...I'd like to see you or anyone else
>    actually address the specific point I raised: that a strengthened 
>    software engineering requirement would be a more productive use of
>    student time than an OS requirement, for those students who are not 
>    to become OS professionals. 
>
>    Not "why is an OS course better than nothing", not "was the OS course
>    you took useful", but "why an OS requirement is better than the 
>    alternative of a strengthened software engineering requirement".  
>
>    I'm still waiting to see someone actually address this issue...
>

I guess there are several of us who certainly think we have already
addressed the issue you speak of, but we may not have done so
successfully or done so in a way that got our point across, so I'll try
it more directly.  (Aside: I think there is good reason to arue that
what an SE curriculum really needs is two extra semesters of English
Composition.)

I think first of all that you're raising a straw man: there are more
degrees of freedom than "we can have OS or more SE but not both."  I
think it would be far more useful to have BOTH a strong OS requirement
AND a strong background in the issues of software engineering.  I also
think (as I said before) that I think there ought to be more emphasis on
the issues that go into software engineering in undergrad programs, or
that there ought to be at least some caveat that we're teaching
chemists, not chemical engineers.

Given that, I still believe that a strong background in operating
systems is ESSENTIAL to becoming an effective software engineer.  I have
three reasons for this:

(1)  The algorithms of operating systems are examples of algorithms that
occur over an over again in a large class of programs.  Operating
systems classes show these algorithms used in a real context; using
these algorithms and talking about the tradeoffs among them (like the
choice of scheduler algorithm) is one of the chances that we have to
describe the sort of things an engineer does.  Operating systems classes
are often the first chance to see a linked list used for anything beside
exercise 11 in the text.

(2) The understanding of the operating system concepts from an OS
course -- as I've mentioned -- can be essential to understanding the
behavior of a program, or predicting the behavior of the program
during design.  (I could go into the war story about a guy I once
worked for who was designing a real-time system with 220 processes
running concurrently on a VAX under VMS.  He dismissed the question of
resources for all those processes with an airy "Oh, processes don't
take up any resources."  He knew project management stuff really well.)

(3) Operating systems offer the first chance in most cases to introduce
things like mutual exclusion and record management (reader-writer
problems).

Note that I'm not claiming that every operating systems class TEACHES
these things; if you get an OS class that does six weeks of queueing
theory and covers the Banker's Algorithm but never discusses the
tradeoffs involved in using secondary store, it may do you little good as
a software engineer.

But if one builds an SE curriculum that teaches these things, it
includes an operating systems course whether one calls it such or not;
if one builds an SE curriculum that DOESN'T teach these things AT ALL,
then (in my opinion) one ought to be arrested.

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