Xref: utzoo comp.edu:2706 comp.software-eng:2531 Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!hellgate.utah.edu!helios.ee.lbl.gov!ucsd!ucsdhub!hp-sdd!ncr-sd!ncrcae!hubcap!billwolf%hazel.cs.clemson.edu From: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) Newsgroups: comp.edu,comp.software-eng Subject: Re: CS education Message-ID: <7184@hubcap.clemson.edu> Date: 26 Nov 89 00:08:13 GMT References: <16171@duke.cs.duke.edu> Sender: news@hubcap.clemson.edu Reply-To: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu Lines: 211 From crm@romeo.cs.duke.edu (Charlie Martin): > [...] 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 perceive the distinction as essentially based upon the level of abstraction involved. At the lowest level, there is the technical worker, who should have a basic understanding of what technical management involves which is reinforced by advanced study and by observation of the technical management in his/her work environment. After a suitable period, a technical worker who has an interest in technical management (we'll assume an appropriate career path for the worker who chooses to concentrate on technical work as a career) and has demonstrated the appropriate qualifications is moved into a position of technical management. At this point, the technical manager should have a basic understanding of what nontechnical management involves (which would include marketing, finance, etc.), which is reinforced by advanced study and by observation of the less-technical management in his/her work environment. At the higher level of non- technical management, an MBA is a fundamental educational requirement, and technical managers who wish to move higher within the organization [i.e., into the CEO's position] will have to get one. Their technical backgrounds will be of relatively little significance except in that certain management skills were obtained during the process of technical management (assuming that the organization's basic operations are not defined around the particular technology under consideration, in which case the technical background will be of greater significance). I would doubt that many technical managers will be interested in the CEO's seat, though; most will probably be satisfied with representing the strategic and tactical capabilities of their chosen technology, moving to the same position within larger organizations if further advancement is desired. >>> 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. >> > 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. We can reasonably assume that each course is the same size: three semester hours. We can reasonably assume that our required OS course fills exactly that amount of space. Now our program has only room for whatever amount of software engineering material it presently contains, and sadly all other space is filled. In order to increase the space devoted to software engineering, we must select a course to kill. We therefore look for courses whose material is of low marginal value relative to our chosen career path. Assuming that our program is not one which is intended to specialize in operating systems, the OS course contains much material which is irrelevant and therefore killable, as does the architecture course (assuming again that this is not an area in which the student intends to specialize). From my particular perspective, that of a person specializing in information systems, OS and architecture represent courses which I would very gladly kill in exchange for the semester-hour space with which to take large quantities of additional software engineering material, if I had it to do all over again. > 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. No inferences can be drawn regarding the undergraduate program at Clemson, since this is not my undergraduate institution. I speak about undergraduate education on the basis of my undergraduate experience at Purdue University. > 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? Everything about the internals of an OS which is hidden from its users. The user interfaces to an OS may well require a bit of explanation as to the definition of certain patterns of interface behavior; for example, it may be necessary to give a scheduling model in order to explain to the user the pattern of behavior which the operating system will present at the user-scheduler interface, and it may be useful to convey to the user the fact that all operating systems having the attribute "Uses The Umptysquat Scheduling Algorithm" will present a similar pattern of behavior. Enough to understand how to use the tool, and no more. > How do you know that you won't be building OS-es? I know that information systems is an extremely large employment market (many, many times larger than the market for OS builders), and that my professional background is strong enough to permit me to decline any requests to do such a thing in the extremely unlikely event that such a request ever comes up. I also know that OS building is a complex and highly specialized field which requires long and specialized study, and that any employer who tries to get a person who does not have the appropriate extensive professional training and career committment to the field to do OS design is destined for a rather spectacular failure. I have absolutely no plans to obtain such qualifications, and I am confident that natural economic selection will see to it that any such employers are rapidly driven into economic extinction and that I will never encounter such a brain-dead employer. > 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 think many of those persons are having difficulty separating the reuseable knowledge from the non-reuseable stuff which was specific to the OS domain, due to the fact that it was "chunked" together during acquisition (as the cognitive psychologists would put it). > [...] 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 [...] You are completely correct in that I agree that the general concepts which are frequently held up as reasons to take an OS course are indeed important and completely deserving of coverage. But it is not the title I object to... it is the domain-specific knowledge which is irrelevant to my future that I find objectionable. I know that my educational dollar is wasted by the study of this material, and that's quite important, but that isn't what REALLY ticks me off. What really kills me is that there is so much wonderful software engineering material out there that I was prevented from studying because I was R-E-Q-U-I-R-E-D to study so many things which were irrelevant. Had I been free to make intelligent and reasonable tradeoffs, I would be much farther along and would have gotten a lot more enjoyment and value out of my education. > All of these discussions (teaching SE, productivity, and licensing) > bring up the question that more and more interests me; it is subtext to > the whole discussion. > > What is software engineering? > > Boehm claims (Software Engineering Economics, pg 16) > > _Software engineering_ is the application of science and mathematics > by which the capabilities of computer equipment are made useful to > man via computer programs, procedures, and associated documentation. > > ....but that doesn't give much guidance to the detailed examination of > what is or is not applicable to learning to be a software engineer. (It > could be read to require the software engineer to know everything about > nearly everything.) But clearly economics do not permit us to study everything; we must consider the marginal costs and marginal benefits of that which we choose to study. An analogy: those who must classify classified information face the dilemma of what level should be used to classify a given bit of information. A naive approach to the problem would choose to default on the side of overclassification, reasoning that the goal of the process is to prevent disclosure and that certainly overclassification would achieve that objective. But there are costs associated with the various levels of protection; if there is information which is being overprotected, that overprotection costs the Government considerable money which could instead be used to more usefully enhance the national defense. Similarly, overeducation is not economically sensible; we must cover that which is relevant, but no more than that. To the extent that CS education covers irrelevant material at the expense of the relevant, the quality of the graduating practitioner will be degraded, with adverse effects on the efficiency of the information processing sector. This effect is then multiplied, since the quality of the information processing sector has strong effects on the quality of the overall economy. Therefore, I consider the failure of the CS educational system to successfully minimize this problem to be an implicit act of economic sabotage. The insulation of the educational system from market forces is sadly preventing the market from applying corrective discipline, but that's another topic... > [...] let's re-cast the question: assume that there existed a professional > engineer's exam for software engineering. (I am convinced that one will > exist at sometime in the future, but that's not germane -- let's just > assume that one DOES exist.) > > What is on the exam? > > I'd propose as a starting point the list of things I laid out in a > previous posting today: theory, major historical applications as > examples of how the theory is applied, some details of the techniques of > software engineering, some discussion of modularity and other tradeoffs. > Does anyone have other topics of interest? How about topics to be deleted? > > Rich d', Bill Wolfe, I'm specifically interested in your thoughts. Oh, please, I'm exhausted!! Can we discuss this in a week or three? > Has it struck anyone else in this discussion that the reason we can't > trust new graduates to write good code on graduation is that we the > academics have taught them to write BAD code BEFORE graduation? > > Is this soluble? I think it is, but this is another long thread which I'd like to put off until I recuperate from this one. Probably around the time I get through with all those turkey sandwiches!!! :-) :-) :-) Bill Wolfe, wtwolfe@hubcap.clemson.edu Brought to you by Super Global Mega Corp .com