Xref: utzoo comp.edu:2697 comp.software-eng:2485 Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!usc!brutus.cs.uiuc.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: <16171@duke.cs.duke.edu> Date: 22 Nov 89 17:33:12 GMT References: <16109@duke.cs.duke.edu> <7147@hubcap.clemson.edu> Sender: news@duke.cs.duke.edu Reply-To: crm@romeo.UUCP (Charlie Martin) Organization: Duke University CS Dept.; Durham, NC Lines: 114 In article <7147@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: >From crm@romeo.cs.duke.edu (Charlie Martin): >>> Business schools exist to produce *non-technical* managers, >> >> 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 ... > > Technical management does not mean "management which uses > quantitative techniques"... it means "management of highly > technical activities", which requires a detailed understanding > of the technology being applied. > Make up your definitions as you like, but managers of technical endeavors consider cost and schedule as well as technical issues. The fact that this takes two different classes of skills leads to many things: - the producer/director separation proposed by Brooks - the fact that moving from technical work into management is often helped by getting an MBA as well. (although in fact the analytic skills involved CAN be learned using the background that most engineers have) - the occasional person who moves into management and doesn't like it, so leaves; the much more common person who moves into management, doesn't like it, isn't good at it, but doesn't have the nerve or the career path to get back to technical work. Propose to me the things that technical managers do AS MANAGERS that are different from other managers. >> 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." > > Given that there are a finite number of semester hours available > in any degree-seeking program, this is precisely the case. > That's nonsense. Precisely non sense. It would only be precisely the case if each course were exactly the same "size", and if there were exactly one opening in the program, of a size that could accomodate either an OS course or an SE course but not both. But stated as you have, it makes exactly as much sense as saying "you can have a semeter of calculus or a semester of software engineering, but not both." If the program at Clemson is so tightly constrained that this is the only choice you have, I certainly wouldn't want to go there. >> 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. > > Not if OS is irrelevant to the student in question. > And this is back (at least) to the issue in question: is operating systems irrelevant to the issue in question? If so, why? I don't believe, and I've stated my reasons at length. Okay, let's hve some facts. What are the parts of OS that are irrelevant unless you are going to build OS-es? How do you know that you won't be building OS-es? How do you explain the number of us who have said that we have found in professional practice that knowledge of OS concepts and issues have been important in non-OS problems? I know you say you've been in practice as well, but I'll put my resume up against yours for authority if that's what you think makes a difference. Basically, is this argument based on *evidence* or belief? What is your evidence? What is the basis for your belief? >> Operating systems classes are often the first chance to see a linked >> list used for anything beside exercise 11 in the text. > > Only if the operating systems classes are coincidentally > the first classes taken after data structures. > >> (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 > > Then let scheduling algorithms be considered in courses on real-time > programming. Scheduling algorithms are by no means going to require > an entire semester of operating systems material, so that still leaves > lots of unneeded material which an OS course would needlessly cover. > >> (3) Operating systems offer the first chance in most cases to introduce >> things like mutual exclusion and record management (reader-writer >> problems). > > Simply because there are not courses on concurrent programming > in general. There are many applications for concurrent programming > which do not involve operating systems. This is simply another > attempt to claim that operating systems are good because of > incidental side effects which should instead be taken directly. > > > Bill Wolfe, wtwolfe@hubcap.clemson.edu Unless I recall my response incorrectly (always a possibility) you've taken out the concluding argument that counters all of the things you've used as responses. That argument is that once you include these things (along with issues of resource allocation and file systems) you've covered the contents of an operating systems course. Is it the TITLE "Operating Systems Concepts" that you object to? You seem to agree that the concepts taught in a course are significant or important, from the above. It is very hard for me to imagine a competent software engineer for ANY domain who is not at least aware of the issues of concurrency and concurrency control, file systems and file structures, resources and their allocation. There are plenty of MIS programs that have to consider these issues! Charlie Martin (crm@cs.duke.edu,mcnc!duke!crm)