dar@nucleus.UUCP (Dario Alcocer) (11/09/89)
> Now let me clarify one thing before my E-mail box overflows... I am NOT > saying or even implying that current CS curricula is not valuable. What > I AM trying to say is that I think it could be a LOT more relevant > (to the real world, vs. the academic world). > I think there is a straightforward explanation for the situation mentioned here. Historically, the function of universities and colleges in Western-style society are to develop an academic elite that advances the technical frontiers, the people whose research will provide new technologies in the future. Only within the last 25(?) years or so have people come to think of universities and colleges as 'degree factories' or glorified technical schools. The main purpose of a university or college education is NOT to provide the necessary skills to graduates to fill entry-level positions in the job market, but to produce a well-educated elite that already have the necessary position in society to make a difference; if you look at the histories of the Ivy league schools, for example, you'll find that the gradutes of the late 19th and early 20th century were from well-to-do families being groomed for positions alredy available to them, and were not concerned about looking for a job. However, since broadening of the student bodies in these institutions, more people, especially middle-class people, go to universities and colleges not to become part of an academic elite, but to get the training necessary to enter the job market. To the extent that is has occured, these institutions have had to stray from their original purpose. I think that the technical school and high schools are the ones in the position to train people for the job market. That's where, I think job training would be both more effective and a better use of educational resources. That's my opinion... what's yours? Dario Alcocer (UC San Diego, '87) San Diego, CA via Nucleus (dar@nucleus.mi.org)
crm@romeo.cs.duke.edu (Charlie Martin) (11/09/89)
In article <6961@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: >From kww@cbnews.ATT.COM (Kevin W. Wall): >> Just once I'd >> like to see a homework assignment in some CS course be something like >> >> "add features X and Y to this 60,000 software system (which the >> students have never seen before) and turn it in next week". > > course here at Clemson University; last semester, we gave students a > large prewritten software system and had them implement several changes > to it as part of their semester project. It *does* happen. > See also "Adding Reviews, Prototyping, and Frequent Deliveries to Software Engineering Projects," Connie U Smith and Charles R. Martin, _Issues in Software Engineering Education_, Fairley and Freeman, eds. Springer Verlag 1989. It *does* happen, no kidding. But it appears to be rather rare. It means that someone has to make an effort preparing the assignments, and it helps if the people doing the assignments and the grading have actually done some maintenance themselves. > In general, I agree. In practically every CS program, students > spend lots of time writing operating systems, etc; this is fine > if a student wants to specialize in this area, but it should not > be required of those who do not. There is far too much software > engineering material, material which would be of great practical > benefit REGARDLESS of application area, which there is not presently > enough time to teach. Why? Because they are off studying operating > systems (as if more than 1% of them would ever make use of the material), > architecture (shouldn't this be left to the computer engineering program?), > and so on. Again, I have nothing against this material for those who > are interested, but I have major disagreements with the proposition that > such material from what today is a fairly remote area of specialization > should be required of ALL students taking a CS program. I think you're completely off the wall here, especially when you're talking about education at the master's degree level or higher. I agree that there is a fairly large area of software engineerin material that would be very useful, and more being discovered/invented every year: there is a fair bit of real science and good engineering that is involved with problems of configuration control, correctness, specification, etc. There is also a lot of stuff that software engineering is sort of stuck with but ought to be part of simple programming literacy, like cleanly realized code, testing plans and schemes, reviews or walkthroughs, etc. In my opinion, it ought not be possible to graduate with a degree in Computer Science without deminstrated ability to write programs, any more than one can have a degree in English Literature without a demonstrated ability to read and write English, or a degree in medicine without knowing anatomy. 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. But HOWEVER: the grounding in things like operating systems, at least in the ways I have seen them taught even at an excessively theory-oriented school at Duke, are ESSENTIAL for the practicing, competent software engineer. Even if you don't write an operating system yourself, there are problems in real-time programming that are essentially operating systems problems, and bugs in real-time programs that have to do with the precise operation of the operating system itself, e.g. the scheduler. 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. And I think the mathematical sophistication that comes from learning computability theory is central to learning, REALLY learning, how to consider correctness in a program, of which software engineering has no which-er. I'm saying this as a person who came to grad school as an experienced software engineer and a firm believer in just the position that Bill Wolfe proposes. I was wrong then. I think Bill is wrong now. Charlie Martin (crm@cs.duke.edu,mcnc!duke!crm)
rsd@sei.cmu.edu (Richard S D'Ippolito) (11/10/89)
In article <9734@june.cs.washington.edu> Peter C. Damron writes: >I would submit that there is not much more than a quarter or semester >worth of material about software engineering that is not taught in some >other CS class. I find this statement fascinating, especially this discussion to now has been about computer science, and not software engineering. Please explain exactly what you mean, particularly, what "software engineering" material is to you. Thanks, Rich -- We use kill ratios to measure how the war is going. We use SLOC ratios to measure how our software is coming. (Idea from Gary Seath) rsd@sei.cmu.edu -----------------------------------------------------------------------------
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (11/10/89)
From wtwolfe@hubcap.clemson.edu (me): > In general, I agree. In practically every CS program, students > spend lots of time writing operating systems, etc; this is fine > if a student wants to specialize in this area, but it should not > be required of those who do not. There is far too much software > engineering material, material which would be of great practical > benefit REGARDLESS of application area, which there is not presently > enough time to teach. Why? Because they are off studying operating > systems (as if more than 1% of them would ever make use of the material), > architecture (shouldn't this be left to the computer engineering program?), > and so on. Again, I have nothing against this material for those who > are interested, but I have major disagreements with the proposition that > such material from what today is a fairly remote area of specialization > should be required of ALL students taking a CS program. From Neal Murphy: > [argues relevance of OS/architecture to systems programming] I do not disagree that writing an OS and/or studying architecture might be useful to systems programmers; however, we must recognize that, as pointed out by the ACM Task Force on the Core of Computer Science, "Many computing graduates wind up in business data processing, a domain in which most computing curricula do not seek to develop competence." (CACM, Jan '89, p. 13). Such graduates have no use for systems programming expertise, and a significant percentage of them are likely to be actively disinterested in working at that low a level. What the OS/architecture requirements are asserting is that these students should be compelled to take such courses anyway, which in my view is ridiculous. > Besides, writing an operating system allows one to use, at least once, > most of what he learned from the CS program: human factors, scheduling > theory, queuing theory, compiler theory, networking. In addition, > the typically quiet, introverted gweep learns how to work in a team, > and learns that no one person can do everything. Amazingly enough, software engineering courses are precisely the courses in which the rest of the CS program is put to work within a classwide project (as opposed to two-or-three-person teams, which is still small enough to avoid effectively demonstrating the issues pertaining to programming-in-the-large...); rather than attempting to provide such things as an incidental side effect of a course which is really about an obscure domain, why not increase the coverage of software engineering so that these things will be achieved as a *primary* objective? > The disadvantage of your idea is that students would be encouraged to > become specialists Quite the contrary, I propose that the increased study of software engineering be done in order to AVOID overspecialization (e.g., into obscure areas like architecture and operating systems, in which very few people are full-time workers these days). A solid background in software engineering prepares one to go out and construct high-quality software in general, regardless of the specific application area. From Peter Damron: > I believe that operating systems and architecutre are two subjects > that undergraduates should learn something about. The projects may or > may not be very applicable to their education, but almost any project > is likely to teach something about software engineering. But notice that what I proposed instead was precisely an increase in the coverage of software engineering!! > I would submit that there is not much more than a quarter or semester > worth of material about software engineering that is not taught in some > other CS class. I would submit that this is (I will try to phrase this delicately) grossly incorrect; if there is any truth to this statement, it is precisely because the amount of software engineering material which is presently being taught is artificially low due to the diversion of teaching resources into the teaching of highly specialized and largely irrelevant material to many people who would rather be learning more relevant things about software engineering instead. From Ian Kluft: > [thinks there should be courses which will "wash out" underachievers] At my undergraduate institution, Purdue University, the big "wash-out" course was Algorithm Design and Analysis, using the Horowitz and Sahni textbook; the nice thing about it was that this material is extremely relevant to computer science practitioners (dynamic programming, branch-and-bound, greedy algorithms, NP-completeness, and so on), so the students could hardly claim that they were unjustly eliminated. Incidentally, there was also a course in the Information Systems route of specialization called Systems Programming, which was 1/2 operating systems and 1/2 compilers; I think this is an excellent start, which should be extended to include surveys of assembly language, computer architecture, and microprogramming, thereby clearing up 9 more semester hours for the increased study of software engineering and other more relevant topics. From Dan Pick: > 1) Is knowledge priceless? No, it has a cost; just ask every tuition-paying student. > operating systems are an active field > of research in which a faculty member may pass on something of > the flavor of researching a body of knowledge, while at the same time > teaching his or her students how to design a new system. True, but I'm arguing that this flavor should be passed along within a context of relevant and interesting material; the way to ensure this within the context of operating systems courses is to see to it that the people who are there took the course because of an interest in the material rather than simply an interest in eventual graduation. From Dick Dunn: % In the traditional nomenclature, the terms "science" and "engineering" are % used in naming disciplines which are relatively "pure" vs "applied". That % is, engineering disciplines are for applying the principles developed in % the corresponding sciences. % % This creates a serious problem for "Computer Science": For the most part % there IS no corresponding engineering discipline, so people expect the % Computer Science departments to provide the "applied science" education as % well. Software engineering is beginning to make some inroads here, but % (a) it's on the borderline of qualifying as "engineering" in the % traditional sense and (b) it's only one narrow area of where "engineering" % is needed to correspond to computer science. [...] % % The greater problem is the dissonance between what many universities think % Computer Science should be and what industry thinks it should be. [...] % We're training people as computer scientists when that's not what they % need or want...but it's as close as they can get to their real interests. Dick is exactly right; this gets back to the letter in September's CACM, "Information Systems is an Engineering Discipline". But until such time as software engineering gets its own department, perhaps within the school of engineering (vs. science), CS departments need to recognize the need to accomodate future engineers as well. From Chris Prael: % There is a basic set of disciplines to engineering. This set seems to % be well taught in civil and mechanical engineering curricula and less % well in electronic engineering curricula. The set seems to be taught % little or not at all in the typical computer science curriculum. % % In my experience, people with CS degrees generally, but not universally, % come out of college trained to function as technicians rather than as % engineers. Technicians have lots of techniques but not much discipline. % They cut and try a lot (formally known as prototyping) and generally put % together something that just about works. % % An engineer is trained to organize and solve a problem in his head. The % ordinary ones simply apply the conventional sollutions with pedestrian % but reliable results. The great engineers devise sollutions that are % works of art. Well said. Bill Wolfe, wtwolfe@hubcap.clemson.edu
peterd@cs.washington.edu (Peter C. Damron) (11/10/89)
In article <34705@regenmeister.uucp> chrisp@regenmeister.uucp (Chris Prael) writes: >There is a basic set of disciplines to engineering. This set seems to >be well taught in civil and mechanical engineering curricula and less >well in electronic engineering curricula. The set seems to be taught >little or not at all in the typical computer science curriculum. I'm not sure I know what you are talking about. Just what is this "basic set of disciplines" that engineers learn? How does it differ from what I would call "tools and techniques"? Excuse my ignorance, Peter. --------------- Peter C. Damron Dept. of Computer Science, FR-35 University of Washington Seattle, WA 98195 peterd@cs.washington.edu {ucbvax,decvax,etc.}!uw-beaver!uw-june!peterd
fitz@CTC.CONTEL.COM (Joe Fitzgerald) (11/10/89)
First, standard disclaimer. This is a very large topic with deep philosophical implications associated with every viewpoint. Following is my viewpoint, just one of many. I learned a helluva lot more about software engineering in one quarter of operating systems than I did in four quarters of calculus, four quarters of physics and 3 quarters of business administration combined, all of which were required. I am in no way an expert on the topic, but they tell me these courses are necessary to teach one how to analyze and solve problems at an abstract level. Yet, I still feel better suited to solving software problems thanks to my operating systems class than any other of the aforementioned. At present I am not writing operating systems or solving differential equations or estimating return on investment. Joe Fitzgerald fitz@ctc.contel.com ----------------------------------------------------------------------- | Contel Technology Center C C C C T T T T T C C C C | | 15000 Conference Center Drive C C T C C | | P.O. Box 10814 C T C | | Chantilly, Va. 22021-3808 C T C | | (703) 818-4154 C C C C T C C C C | -----------------------------------------------------------------------
peterd@cs.washington.edu (Peter C. Damron) (11/10/89)
In article <4863@ae.sei.cmu.edu> rsd@sei.cmu.edu (Richard S D'Ippolito) writes: >In article <9734@june.cs.washington.edu> Peter C. Damron writes: > >>I would submit that there is not much more than a quarter or semester >>worth of material about software engineering that is not taught in some >>other CS class. > >I find this statement fascinating, especially this discussion to now has >been about computer science, and not software engineering. Please explain >exactly what you mean, particularly, what "software engineering" material >is to you. I wrote that paragraph mainly to stir up discussion. I "hear" a lot of "talk" about the need for more software engineering, but little about what people mean by software engineering. Tentative definition: Software engineering is the facilitation of applications that require software solutions. So, to me that includes everything already taught in computer science, plus maybe some more. But keep in mind that the above statement was made in the context of undergraduate education, so not even everything about computer science or software engineering can be taught. Some things like software lifecycles, specification, documentation, testing, and environments are not generally taught in any computer science class, and could be included in a software engineering class. That covers a lot of material, but is it worth taking up more than one undergraduate class? I am not convinced that it is. No doubt I left off someone's software engineering topic of interest, and I'm sure you'll let me know if I did. Peter. --------------- Peter C. Damron Dept. of Computer Science, FR-35 University of Washington Seattle, WA 98195 peterd@cs.washington.edu {ucbvax,decvax,etc.}!uw-beaver!uw-june!peterd
jrj1047@ultb.UUCP (J.R. Jarrett) (11/10/89)
In article <34705@regenmeister.uucp> chrisp@regenmeister.uucp (Chris Prael) writes: >There is a basic set of disciplines to engineering. This set seems to >be well taught in civil and mechanical engineering curricula and less >well in electronic engineering curricula. The set seems to be taught >little or not at all in the typical computer science curriculum. Yes, I agree there is a basic set of disciplines to engineering. However, they are based on *physical* laws (How much force can a piece of steel take before it collapses, etc...) Software is an *artificial* construct, much more complex than a bridge, or circuit. Perhaps an oversimplification, but you get the idea. >> What did you learn? > >Between a math BS (from UW) and 5 years of motor racing, I learned to be >a pretty effective engineer of software. Ah, there's a big difference between a Mathematics (especially a pure math degree) and a CS degree. I have a BA with majors in both math and computer science. In the computer science curriculum, I learned about such fun things as finite state machines, data flow diagrams, and operating systems :-}. But, in math, I learned how to attack problems, systematically solve them and show how they were solved. With that kind of background, one can learn to do anything (ok, an exaggeration! :-))) With a math degree, you're more flexible. I think CS should take a look at sucessful mathematics programs and try to become a bit more like them. -- +-------------------------------------------------------+ | Jim Jarrett, Rochester Institute of Technology | | (716) 271-7019 jrj1047@ultb.isc.rit.edu | +---------------- rutgers!rochester!ritcv!ultb!jrj1047 +
Jerome_V_Vollborn@cup.portal.com (11/10/89)
Much of the discussion in this thread centers on how computer science courses should produce software engineers. I my view (perhaphs somewhat naive) computer science should teach students about the theory underlying the correct construction of software (undergraduate level) and how to extend those theories (graduate level). Neither of these directly concerns the production of software: that is the job of software engineers. Whether we want to go through another round of title inflation to computer scientists or retitle the courses being given at most colleges, we should be more careful about terms or explain what is meant when a term is used. As an aside, a couple of weeks ago I interviewed a person about to graduate from the University of California at Berkley with a PhD in computer science. He has been doing research in machine control. When I asked him what design approach he had been using, he said that since he was doing research no explicit (my word, not his; he didn't know what a formal design method is) design method could be used. Further questioning showed that he could not name or describe any explicit design method! As a California tax payer I am very unhappy. Not only has my tax money to support this person's education been misspent, but much of this person's time has been wasted.
rang@cs.wisc.edu (Anton Rang) (11/10/89)
In article <11064@cbnews.ATT.COM> kww@cbnews.ATT.COM (Kevin W. Wall) writes: >Exactly! But of course "code stealing" (or "stealing" of any kind) is another >thing which is strongly discouraged in traditional education. Some undergrad departments kill user accounts between quarters. This seriously discourages going back and reusing code from previous classes! Also, I've noticed that a lot of algorithm/data structure courses never actually mention that there might be *uses* for what's being taught.... A lot of CS curriculums, IMHO, don't have any sense of continuity or connections between courses--the classes are presented in isolation, and it's pretty rare for teachers to point out that techniques taught in one course can be useful in another. (I wouldn't have thought this is necessary, but some students seem to be rather dense... 1/2 :-) >I don't know how many green horns fresh out of grad school I've worked with >who wasted needless company time [ ... writing new code instead of reusing >existing code ... ] Seems to me like grad schools/academic CS in general encourage writing new code (the NIH syndrome). How many universities have hacked up their own UNIX versions? For that matter, when presenting a thesis project, it looks more impressive if you wrote tons of new code. :-) > IMHO, I think a large part of the blame for >the software crisis has to be placed on the shoulders of the formal education >system. To put it bluntly, CS departments are not teaching the necessary >skills to be successful in industry. I agree totally...software engineering is missing almost totally. Undergrad programs emphasize working on individual projects, which is good (teaching "the basics"), but rarely have any work done by more than a 2-person team. Grad schools (even MS programs) really don't teach much in terms of programming, at least in my experience; they cover more advanced theory in various fields. If I was advising a company, I'd probably advise hiring BS types for generic programming positions--I am totally unconvinced that a grad degree helps here, and BS's are cheaper. Grad degrees hopefully imply more knowledge about certain areas (i.e. an MS in database probably knows lots about concurrency control--at least the theory, if not practice!). However, I don't know of any grad programs which teach coding/testing/designing, though I'm sure there are at least a few out there. Anton Disclaimer: I'm a grad student, so my comments about grad students can probably be taken with a grain of salt... :-) +----------------------------------+------------------+ | Anton Rang (grad student) | rang@cs.wisc.edu | | University of Wisconsin--Madison | | +----------------------------------+------------------+
sdm@brunix (Scott Meyers) (11/11/89)
In article <23871@cup.portal.com> Jerome_V_Vollborn@cup.portal.com writes: >As an aside, a couple of weeks ago I interviewed a person about to >graduate from the University of California at Berkley with a PhD in >computer science. He has been doing research in machine control. >When I asked him what design approach he had been using, he said that >since he was doing research no explicit (my word, not his; he didn't >know what a formal design method is) design method could be used. >Further questioning showed that he could not name or describe any >explicit design method! As a California tax payer I am very unhappy. >Not only has my tax money to support this person's education been >misspent, but much of this person's time has been wasted. Just out of curiosity, given that he was doing research and wasn't necessarily sure what the final specification of his system was supposed to be, what design methodology would you have recommended that he employ? As for misspending your tax dollars, did you arrive at that conclusion by examining his research to see if it was worthwhile, or did you simply stop thinking when you found that he couldn't satisfactorily pass your software engineering litmus test? Scott sdm@cs.brown.edu
rcd@ico.isc.com (Dick Dunn) (11/11/89)
Bill Wolfe said: > ...however, we must recognize > that, as pointed out by the ACM Task Force on the Core of Computer > Science, "Many computing graduates wind up in business data processing, > a domain in which most computing curricula do not seek to develop > competence."... I won't dispute that "computing graduates" (a broad term, probably intended so) end up in BDP. I certainly hope that CS curricula, in particular, *don't* try to train people for it. That is entirely as it should be! With the exception of perhaps the most theoretical < 1% of work in data base theory and a few other niches, you don't need a CS degree for BDP. It's foolish to pretend that you do. The problem lies in having people get a degree in field X, then get a job in field Y--and complaining that their X training isn't any good for Y. Computer Science departments are NOT at fault for failing to train people for non-computer-science jobs! Computer Science is a science, not a high- tech trade-school profession. What we need to do is to identify and separate the engineering and vo-tech curricula from the science; then we can stop this foolishness of making people think you get a CS degreee to become a programmer! I think we need three fields: Computer Science Software Engineering Programming Put the Programming into trade schools and junior colleges. And, at the risk of offending lots of junior-college types, let's stop pretending that Computer Science is what's being taught there. Software engineering might be taught at either JC or 4-yr, but as usual the levels would be quite different. You could mix CS and SE programs--that's plausible, and it's done in other fields. (For example, my undergrad degree is "Engineering Physics", which was a mixture of the stock engineering courses--applied math, thermo, diffeq, num anal, p chem,...--with both experimental and theoretical physics courses.) But if you do that, people go into the CS half of it knowing that they've bought into a half-theoretical discipline; they don't have a basis for complaining that the CS isn't directly useful in the short term. Bill also said: > ...But until > such time as software engineering gets its own department, perhaps > within the school of engineering (vs. science), CS departments need to > recognize the need to accomodate future engineers as well. I can buy that. But we'd better (1) realize that we've got a marginal match of degree to eventual job, and (2) get busy with the engineering curriculum. Actually, some CS departments ARE in engineering colleges. That, I think, is an unhappy marriage-of-convenience...but as long as it stands, it does obligate the CS departments to pay more than lip service to the need for practical courses. The other side of it, though, is the series of complaints in this newsgroup about CS course material not being relevant to software industry jobs. That's a problem with student attitudes, I think. If you don't want to hear about queuing theory, automata theory, finite math, graph theory, and all the rest, STAY OUT OF CS! -- Dick Dunn rcd@ico.isc.com uucp: {ncar,nbires}!ico!rcd (303)449-2870 ...Keep your day job 'til your night job pays.
chrisp@regenmeister.uucp (Chris Prael) (11/11/89)
From article <9759@june.cs.washington.edu>, by peterd@cs.washington.edu (Peter C. Damron): > In article <34705@regenmeister.uucp> chrisp@regenmeister.uucp (Chris Prael) writes: >>There is a basic set of disciplines to engineering. This set seems to >>be well taught in civil and mechanical engineering curricula and less >>well in electronic engineering curricula. The set seems to be taught >>little or not at all in the typical computer science curriculum. > I'm not sure I know what you are talking about. > Just what is this "basic set of disciplines" that engineers learn? > How does it differ from what I would call "tools and techniques"? Nor am I particularly sure of what you mean by "tools and techniques", I made an assumption based on fairly extensive experience and observation. If you don't mind, I will include a bit of your subsequent posting in this. > I "hear" a lot of > "talk" about the need for more software engineering, but little about > what people mean by software engineering. One must first recognize that an item of software is an artifact. A C compiler is just as much an artifact as is a suspension bridge, an automobile, or a stereo receiver. It is not functional to differentiate these artifacts by the degree of concreteness or abstraction. The main points are that each of these artifacts has a use or range of uses, that each was designed and built by someone, and that each performs well when it is applied appropriately. There are two basic styles, or paradigms, of the process of designing and building: the technician model and the engineer model. We have all seen plenty of examples of both models at work. The technician model depends mainly on rote. Typically, a technician examines a problem until a match is found to a previous experience. The previous experience is then replicated concretely, possibly with minor variations. If the technician reaches a point at which the assumed match fails, he may undo some or all of his work to that point. He would then start another search for a matching experience to try. Names for this model in various environments are "cut and try", "blacksmithing", and "prototyping". It is effective when applied to very small projects. We all use it around the house to fix the car or patch the roof. It is not particularly effective when the project is large enough to involve more people. The engineering model is superficially similar but quite different in fact. One must first recognize that engineering is a social act. Unless a project is very trivial, the activities of (often large) numbers of people must be co-ordinated. An engineer with poor communication skills is a functonal cripple. Often, the engineer's objective is initially vaguely defined. So, the first discipline of an engineer is the patience to research and analize an issue with the object of isolating a solvable problem. The next phase is global (or external, or functional) design. Designing is superficially similar to the technician's cutting and trying, but it is done mainly or entirely in the head. The engineer's focus, in this phase, is satisfying the requirements that were given or developed in the previous phase. Implementation details are largely ignored. The third phase is the design of the implementation, also called internal design or detail design. Only after each of these phases has been performed and the results reviewed and revised and re-reviewed, does the engineer start the actual implementation. The implementation phase is the one in which the "tools and techniques" are used. Obviously, the effectiveness of the definition and design phases are is affected by breadth or narrowness of the engineer's experience of "tools and techniques". So, it is reasonable to say that a broad exposure to "tools and techniques" is a necessary condition in the training of an engineer in a specific field. But, it is equally clear that the exposure is not even remotely sufficient. A student in computing who is only exposed to "tools and techniques" without being taught to analize, design, and review has been equipped only to function as a technician, not as an engineer. The differences between the product of an engineer and that of a technician are grossly apparent in effectiveness, in easthetic appeal, in cost, and in timeliness. Chris Prael
chrisp@regenmeister.uucp (Chris Prael) (11/11/89)
From article <5470@nucleus.UUCP>, by dar@nucleus.UUCP (Dario Alcocer): > I think that the technical school and high schools are the ones in the > position to train people for the job market. That's where, I think job > training would be both more effective and a better use of educational > resources. I think that I would rather that my doctor, dentist, lawyer, and the person who designed the next bridge I drive over (or under) had a little more training than can be obtained from a high school or a technical school. Chris Prael
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (11/12/89)
From dar@nucleus.UUCP (Dario Alcocer): > I think that the technical school and high schools are the ones in the > position to train people for the job market. Two major problems with this: 1) Technical schools generally do not go above the associate's degree level; if they start going higher, they are thought of as universities (e.g., Institutes of Technology). 2) If there were two segregated systems, one for researchers and another for practitioners, the current problems we have with researchers being too loosely connected to industrial reality and practitioners failing to keep up with important research developments will become even worse than they already are. Thus, exacerbating the existing lack of communication between researchers and practitioners by shifting the task of educating practitioners to a newly expanded technical school system is not exactly a proposal that I can get overly excited about. The only reasonable solution is to provide at least two tracks within the university system: a research track and a practitioner's track. If this were combined with several other mechanisms by which meaningful dialogue would be facilitated between the two communities, then we would be well on our way to a much-improved system. Bill Wolfe, wtwolfe@hubcap.clemson.edu
Jerome_V_Vollborn@cup.portal.com (11/13/89)
Scott Meyers (sdm@cs.brown.edu) writes: > >Just out of curiosity, given that he was doing research and wasn't >necessarily sure what the final specification of his system was >supposed to be, what design method would you have recommended he >employ? in response to my posting about a PhD candidate doing research in machine control (the PhD was in computer science from University of California at Berkley). Personally I have had good results with object oriented design ala Grady Booch as extended by EVB Software Engineering (contact Ed Berard at Berard Software Engineering or Brad Balfour at EVB Software Engineering for details). There are two main points in response to Scott's questions: (1) the object of the research was machine control (which was well done in this case) not building software; and (2) time spent debugging software was time stolen from machine control research. The person has developed a knowledge base that would be valuable to my company but I find the attitude that if you don't know everything about a problem you can't use an explicit design method to be almost criminal (product liability juries find it negligent). In virtually every project I have done, I did not have all of the information needed. I have had to go ask questions, make judgements about what I thought the users wanted, and had to go back and modify the software to do what the users really wanted (but couldn't coherently state). However for the last ten years I have used explicit design methods starting with Yourdon and Constantine's method (aka SA/SD). I am still studying formal methods but haven't applied one yet. Jerome Vollborn (Jerome_V_Vollborn@cup.portal.com or uunet!lci386!jerome)
kcr@netxdev.DHL.COM (Ken Ritchie) (11/14/89)
In article <9760@june.cs.washington.edu> peterd@june.cs.washington.edu.cs.washington.edu (Peter C. Damron) writes: >In article <4863@ae.sei.cmu.edu> rsd@sei.cmu.edu (Richard S D'Ippolito) writes: > >I wrote that paragraph mainly to stir up discussion. I "hear" a lot of >"talk" about the need for more software engineering, but little about >what people mean by software engineering. > >Tentative definition: Software engineering is the facilitation >of applications that require software solutions. > >So, to me that includes everything already taught in computer science, >plus maybe some more... What about Tony Wasserman's DEFINITION and discussion, described in paper(s), about 10 (+/-3) years ago? [I hope I'm crediting the right person here!] As I recall, he described a 5-faceted program of inter-disciplinary studies (or competency) -- one of which was computer science (CS). Others included important "real life" skills for teamwork, administration, planning, and such. [I'll try to locate my copy, so I can give you a specific reference for this.] I suggest we review the existing work, and build on (or deviate from) that. _______________________________________________________________________________ "So when do we get to do some programming?" -- anonymous software engineer Ken Ritchie (a.k.a. KCR) Usenet: ...!uunet!netxcom!netxdev!kcr NetExpress Communications, Inc. 1953 Gallows Rd, Suite 300 FAX: USA (703) 749-2375 Vienna, Virginia (USA) 22182 Voice: USA (703) 749-2268 _______________________________________________________________________________
rsd@sei.cmu.edu (Richard S D'Ippolito) (11/14/89)
In an earlier article, author not relevant, the following comments were made about CS education: >I learned a helluva lot more about software engineering in one quarter of >operating systems than I did in four quarters of calculus, four quarters of >physics and 3 quarters of business administration combined, all of which were >required. I am in no way an expert on the topic, but they tell me these >courses are necessary to teach one how to analyze and solve problems at an >abstract level. Yet, I still feel better suited to solving software problems >thanks to my operating systems class than any other of the aforementioned... The above seems to summarize a widely-held, but nonetheless mistaken viewpoint of what engineering is, so I will use it as the basis of my comment. I suspect that no engineering is taught in any of the stated courses, for engineering is not about solving problems -- it is about setting them. Rich -- We use kill ratios to measure how the war is going. We use SLOC ratios to measure how our software is coming. (Idea from Gary Seath) rsd@sei.cmu.edu -----------------------------------------------------------------------------
chrisp@regenmeister.uucp (Chris Prael) (11/14/89)
From article <1989Nov10.210835.3884@ico.isc.com>, by rcd@ico.isc.com (Dick Dunn): > Computer Science departments are NOT at fault for failing to train people > for non-computer-science jobs! If there were such a thing as a "computer science job" outside of a college or univerisity, you would be right. There is not. > Computer Science is a science, not a hightech trade-school profession. I have been seeing this assertion for about 15 years now and I have yet to see any justification for it. Just where is the "science"? Chris Prael
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (11/14/89)
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. > Even if you don't write an operating system yourself, there > are problems in real-time programming that are essentially operating > systems problems, and bugs in real-time programs that have to do with > the precise operation of the operating system itself, e.g. the > scheduler. 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. > 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. > And I think the mathematical sophistication that comes from learning > computability theory is central to learning, REALLY learning, how to > consider correctness in a program, of which software engineering has > no which-er. This was not disputed. Bill Wolfe, wtwolfe@hubcap.clemson.edu
chrisp@regenmeister.uucp (Chris Prael) (11/14/89)
From article <8911092042.AA21382@ctc.contel.com>, by fitz@CTC.CONTEL.COM (Joe Fitzgerald): > I learned a helluva lot more about software engineering in one quarter of > operating systems than I did in four quarters of calculus, four quarters of > physics and 3 quarters of business administration combined, all of which were > required. If the four quarters of calculus you took were at all typical, the were all cookbook and no theory. No-one learns to think from memorizing that trash. It wasn't until I got into the second and third year stuff that they started teaching material of real value. First year calculus in not taught for any reason having anything to do with the education of mathematicians. It is taught because the teaching of physics and most forms of engineering is crippled without it. Chris Prael
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (11/14/89)
From crm@romeo.cs.duke.edu (Charlie Martin): > [argues in favor of an OS requirement] > I'm saying this as a person who came to grad school as an experienced > software engineer and a firm believer in just the position that Bill > Wolfe proposes. [i.e., replacing it with software engineering work] Well, as a person who came to grad school as an experienced software engineer and is about to leave grad school even more strongly convinced that the requirement should be for software engineering and not OS, 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... Bill Wolfe, wtwolfe@hubcap.clemson.edu
matt@bacchus.esa.oz (Matthew Atterbury) (11/14/89)
In article <20410@brunix.UUCP> sdm@norton.UUCP (Scott Meyers) writes: > [deleted] design methodology [deleted] ^^^^^^^^^^^ Futher to my exhortation to read "Jackson: System Development", he spends a few pages explaining why it is design *method*, and NOT methodology ... yet another good reason to read it [now!]. cheers, matt. p.s. nothing personal Scott, there are plenty of other comp.software-eng posters i could have "picked on"! :-) -- ------------------------------------------------------------------------------- Matt Atterbury [matt@bacchus.esa.oz] Expert Solutions Australia, Melbourne UUCP: ...!uunet!munnari!matt@bacchus.esa.oz "klaatu barada nikto" ARPA: matt%bacchus.esa.oz.AU@uunet.UU.NET "life? don't talk to me about life!"
murphyn@cell.mot.COM (Neal P. Murphy) (11/14/89)
In article <7024@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: >... > 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. >... Addressing undergraduate education, allow me to stand by my original statement >in Newsgroups: comp.software-eng > Subject: Re: Maintenance > Message-ID: <1989Nov6.192410.13870@world.std.com> > References: <1337@accuvax.nwu.edu> <11064@cbnews.ATT.COM> that writing an operating system is an excellent means of teaching a student: 1) How to use most of what he has learned while in school 2) That there is at least one practical use for each of the many things he has learned while in school Even in light of the topic here in Comp.Edu, the statement stands. However, I do agree that more software engineering needs to be taught. (Computing educators need to learn a great deal as well. More on this later.) A software engineering thread should be introduced in the earliest CS courses, increasing in size and strength to approximate re-rod in the advanced courses. Students today need to learn not only how to do what will be required of them in industry, but they also need to learn how to do it well, how to do it safely, how to do it within ethical and moral guidelines. In addition, they also need to learn how to learn on their own. (After all, this is what college is all about, is it not? In grammar school, we are taught the basics. In high school, we learn the fundamentals of business and science and industry. In college, we learn how to learn on our own, how to teach ourselves.) Now, computing educators (and educators in general) still have a lot to learn. For that matter, everyone who is required to develop a curriculum should be required to study the development of computer science over the past 20 years. Mistakes have been made, essentials have been overlooked, and egos have halted further development. But, we can all see that it is a rapid development of a new branch of knowledge, a development the likes of which we have not before had the opportunity to document and examine. My examination of it leads me to believe that we must determine what the basics and fundamentals are, and remove the teaching of these to grammar and high school levels, where they belong. This will leave the study of advanced computing science and software engineering to those in college, where they can concentrate on formalizing their personal education process, i.e., how to learn to do new tasks within the afore-mentioned safety, moral, ethical, and quality guidelines. Of course, once this is done, where does that leave graduate programs? (I am now addressing post-graduate education.) I suspect that most graduate programs are similar to the one with which I am familiar. It is designed for students who have a degree in an unrelated field. They would be better off enrolling in the undergraduate program. A graduate program should be reserved for advanced (beyond undergraduate) study in the particular field. Upon enrollment in a graduate CS program, you would already be well-versed in the practices and purposes of software engineering, and in the fundamental structures and methods of software design. You could then concentrate on building new structures and methods based on those you already know. Computing education still needs to have formal and standard practices and methods defined, from the grammar school level all the way up to post-graduate study. Am I upset or disappointed at its current state? No, because the field is only twenty years old. Let's not argue over who is right and who is wrong. Let us discuss the issues and try to determine the better course of action, and then implement the action in our education system. NPN ...!uunet!motcid!murphyn
peterd@cs.washington.edu (Peter C. Damron) (11/15/89)
In article <7024@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: > 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... Well, I have a pretty good idea of what you mean by an "OS course", but I'm not sure I know what you mean by a "strengthened software engineering requirement". Do you have some curriculum in mind? Perhaps the reason people answered in support/opposition to the OS course is that they understood that part of the question. Just trying to nail down those requirements, Peter. --------------- Peter C. Damron Dept. of Computer Science, FR-35 University of Washington Seattle, WA 98195 peterd@cs.washington.edu {ucbvax,decvax,etc.}!uw-beaver!uw-june!peterd
ofut@hubcap.clemson.edu (A. Jeff Offutt) (11/15/89)
From article <7024@hubcap.clemson.edu>, by billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ): > From crm@romeo.cs.duke.edu (Charlie Martin): >> [argues in favor of an OS requirement] >> I'm saying this as a person who came to grad school as an experienced >> software engineer and a firm believer ... >> ... [i.e., replacing it with software engineering work] > Well, as a person who came to grad school as an experienced > software engineer and is about to leave grad school even more > strongly convinced that the requirement should be for software > engineering and not OS ... Here's one of my ideas for a perfect software engineering project: An operating system. Another one: A compiler There are many good software engineering projects ... luckily some of them are often used in other classes. Saves us the trouble of teaching all that "application dependent knowledge" before starting the project ... :-) -- Jeff Offutt Department of CS, Clemson University, Clemson SC (803) 656-5882 Internet: ofut@clemson.edu
gds@oahu.cs.ucla.edu (Greg Skinner) (11/15/89)
I just thought I'd throw in a description of what MIT's software engineering class covered when I took it (6 years ago). * Approaches to software development -- top-down vs. bottom-up, modular design, etc. * Formal semantics of data structures -- invariants for the data structures, abstraction functions for the data structures, etc. * Methods of testing software * Documentation * How to go from software specifications to software development The emphasis on the programming assignments we had (text formatter, "mini" macsyma, and a text editor) was to design, test, and document the software. Implementation was only worth about 20% of the grade. The text editor was a team project (3-4 people). The software engineering class is a prerequisite for the compiler class, where teams build a full compiler. --gregbo
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (11/15/89)
From ofut@hubcap.clemson.edu (A. Jeff Offutt): > Here's one of my ideas for a perfect software engineering project: > An operating system. Another one: A compiler. There are many good > software engineering projects ... luckily some of them are often used > in other classes. Saves us the trouble of teaching all that "application > dependent knowledge" before starting the project ... :-) And each of these will be excellent software engineering projects for people for which these application domains are relevant. There are many domains in which software engineering projects can be done; information systems domains, for example. And in courses on information systems, it is reasonable to expect that a software engineering project will be completed as part of the course. But just as it is not reasonable to require operating systems people to complete an information systems project, neither is it reasonable to require people who wish to become information systems software engineers to complete an operating systems project. Instead, there exist domains which are reasonably uncomplicated, such as gradesheet management, which are quite well-suited for use as a basis for a general-purpose software engineering project. Since the domain is simple and easily understood, the software engineering course can focus instead upon software development processes, software project management, requirements analysis, technical communication, configuration management, quality assurance, formality, performance analysis, metrics, standards, verification and validation, security, human factors, and so on; topics which will be of considerably greater value to the future practitioner. Once such a general-purpose software engineering project has been completed as part of the first software engineering course, the student can proceed into more specific domains (yes, even operating systems) in which their software engineering skills can be applied. Since more advanced software engineering material is highly desirable for any future practitioner, I expect that such advanced courses will become quite popular once students find themselves liberated from the burden of studying irrelevant domains. Bill Wolfe, wtwolfe@hubcap.clemson.edu
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (11/16/89)
From peterd@cs.washington.edu (Peter C. Damron): > Well, I have a pretty good idea of what you mean by an "OS course", > but I'm not sure I know what you mean by a "strengthened software > engineering requirement". Do you have some curriculum in mind? I listed some topics in an earlier posting; any or all of these could be covered. The idea is to trade off operating systems for another, more advanced course in software engineering. One example might be an entire course on software verification, validation, and measurement. (Such a course is offered here...) Bill Wolfe, wtwolfe@hubcap.clemson.edu
UH2@PSUVM.BITNET (Lee Sailer) (11/16/89)
In article <7036@hubcap.clemson.edu>, ofut@hubcap.clemson.edu (A. Jeff Offutt) says: >Here's one of my ideas for a perfect software engineering project: > An operating system. > >Another one: > A compiler > I stongly disagree, for two reasons. First, these projects break too nicely into well known "pieces" that can be divvied up among project members. Figuring out how to divvy things up is often the hard part, it the real world. Second, the "user interfaces" for these is too well established. Software Engineers need more experience with meeting the needs of end users, so some project where there is less received wisdom is appropriate. With that in mind, how about a HyperText system? Nobody really agrees on what it should do or how it should work. lee >There are many good software engineering projects ... luckily some of them >are often used in other classes. > >Saves us the trouble of teaching all that "application dependent knowledge" >before starting the project ... :-) >-- >Jeff Offutt >Department of CS, Clemson University, Clemson SC (803) 656-5882 >Internet: ofut@clemson.edu
hutch%citron.cs.clemson.edu@hubcap.clemson.edu (David Hutchens) (11/16/89)
From article <20410@brunix.UUCP>, by sdm@brunix (Scott Meyers): > > Just out of curiosity, given that he was doing research and wasn't > necessarily sure what the final specification of his system was supposed to > be, what design methodology would you have recommended that he employ? > > Scott > sdm@cs.brown.edu Iterative Enhancement (Basili, Brooks, etc.), of course. Can it still be true that most people actually believe in the waterfall model of the life cycle? David Hutchens hutch@hubcap.clemson.edu
rsd@sei.cmu.edu (Richard S D'Ippolito) (11/16/89)
In article <7036@hubcap.clemson.edu> A. Jeff Offutt writes: >Here's one of my ideas for a perfect software engineering project: > An operating system. ...Another one: A compiler Please explain how these require any engineering methods and relate to anything that goes on in the industries that produce software-dependent systems. Rich -- We use kill ratios to measure how the war is going. We use SLOC ratios to measure how our software is coming. (Idea from Gary Seath) rsd@sei.cmu.edu -----------------------------------------------------------------------------
madd@world.std.com (jim frost) (11/16/89)
UH2@PSUVM.BITNET (Lee Sailer) writes: >In article <7036@hubcap.clemson.edu>, ofut@hubcap.clemson.edu (A. Jeff Offutt) >says: >>Here's one of my ideas for a perfect software engineering project: >how about a HyperText system? Nobody really agrees on what >it should do or how it should work. In the software engineering course I took at Boston Univ, this is exactly what we had to do. "Implement a hypertext system any way you want." It was educational for me; I got to see what happened when the media chosen was relatively unknown to most of the members of a group (one group implemented theirs in lisp under emacs; one programmer did most of the work because he was the only one who knew lisp), and what happens if you split the members of a group into the functional parts outlined in Mythical Man Month (which is what my group did, with excellent success). This kind of project is interesting because it is simple enough to be done in a couple of weeks, but is useful and touches many of the same implementation problems as you find in an operating system, without being overly complex. I'm still pretty proud of our original design, although the user interface could have been much snappier. A good SE project, but bzs was always good at finding neat projects for us to do :-). jim frost software tool & die "The World" Public Access Unix for the '90s madd@std.com +1 617-739-WRLD 24hrs {3,12,24}00bps
ron@woan.austin.ibm.com (Ronald S. Woan) (11/16/89)
In article <4943@ae.sei.cmu.edu>, rsd@sei.cmu.edu (Richard S D'Ippolito) writes: > In article <7036@hubcap.clemson.edu> A. Jeff Offutt writes: > > >Here's one of my ideas for a perfect software engineering project: > > An operating system. ...Another one: A compiler > > Please explain how these require any engineering methodsand relate to > anything that goes on in the industries that produce software-dependent > systems. I don't know what the original poster intended, but here's a few reasons that I feel that both of these projects are good. Operating systems projects can teach students about scheduling and interprocess communications and other concepts that can be applied to a great variety of general programs. Not to mention that the better you understand operating systems designs, the more able you will be to take advantage of the operating systems. In much the same light, compiler projects can give programmers have a good idea of how to write code that can be better optimized in general. Not to mention, the experience with lexical analysis and parsing can be very valuable in many situations. In fact, just today I had to work with a YACC-like program for generating a parser in a CAD design tool. Ron +-----All Views Expressed Are My Own And Are Not Necessarily Shared By------+ +------------------------------My Employer----------------------------------+ + Ronald S. Woan (IBM VNET)WOAN AT AUSTIN, (AUSTIN)ron@woan.austin.ibm.com + + outside of IBM @cs.utexas.edu:ibmaus!auschs!woan.austin.ibm.com!ron + + last resort woan@peyote.cactus.org +
rsd@sei.cmu.edu (Richard S D'Ippolito) (11/17/89)
The following article of Chris Parel makes many excellent points, which I
would like to emphasize:
In article <34740@regenmeister.uucp> Chris Prael writes:
=One must first recognize that an item of software is an artifact. A C
=compiler is just as much an artifact as is a suspension bridge, an
=automobile, or a stereo receiver. It is not functional to differentiate
=these artifacts by the degree of concreteness or abstraction. The main
=points are that each of these artifacts has a use or range of uses, that
=each was designed and built by someone, and that each performs well when
=it is applied appropriately.
Right!
=There are two basic styles, or paradigms, of the process of designing
=and building: the technician model and the engineer model. We have all
=seen plenty of examples of both models at work.
=
=The technician model depends mainly on rote. Typically, a technician
=examines a problem until a match is found to a previous experience. The
=previous experience is then replicated concretely, possibly with minor
=variations. If the technician reaches a point at which the assumed
=match fails, he may undo some or all of his work to that point. He
=would then start another search for a matching experience to try.
=The engineering model is superficially similar but quite different in
=fact...
=Often, the engineer's objective is initially vaguely defined. So, the
=first discipline of an engineer is the patience to research and analize
=an issue with the object of isolating a solvable problem.
This is right on the mark! From Tomas Maldonado, "The Aspen Papers":
"Therefore we must say that for the moment the most distinctive
characteristic of man is not his capactiy to solve problems but
more his capacity to set them."
=...So, it is reasonable to say that a broad exposure to
="tools and techniques" is a necessary condition in the training of an
=engineer in a specific field. But, it is equally clear that the exposure
=is not even remotely sufficient.
=
=A student in computing who is only exposed to "tools and techniques"
=without being taught to analyze, design, and review has been equipped
=only to function as a technician, not as an engineer.
=
=The differences between the product of an engineer and that of a
=technician are grossly apparent in effectiveness, in aesthetic appeal,
=in cost, and in timeliness.
=
=Chris Prael
Excellent! D. Schoen, in "The Reflective Practicioner", concludes:
I have become convinced that universities are not devoted to the
production and distribution of fundamental knowledge in general.
They are institutions committed to the most part to a particular
epstimology, a view of knowledge that fosters selective inattention
to practical competence and professional artistry. ... By 1967
engineering design had virtually disappeared from ciricula and the
question of the relationship between art (problem framing) and
science (problem solving) was dead.
Happily, a few institutions now require courses in engineering design at the
undergraduate and graduate levels. However, I have yet to see these kinds
of courses required for computer science students, at any level.
Rich
--
We use kill ratios to measure how the war is going.
We use SLOC ratios to measure how our software is coming.
(Idea from Gary Seath) rsd@sei.cmu.edu
-----------------------------------------------------------------------------crm@romeo.cs.duke.edu (Charlie Martin) (11/17/89)
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)
sbw@naucse.UUCP (Steve Wampler) (11/17/89)
I'm not sure where I personally stand on this whole mess, but I've
noticed a trend in some of the arguments that disturbs me. There
seems to be a feeling (correct me if I'm wrong) that CS programs
should concentrate more on teaching the tools of programming and
less on specific topics - the general argument is something along
the lines of "they [the students] aren't likely to *really* do
topic X, but they'll be programming, so let's teach them to
program right."
Now, I agree with the idea of "teaching them to program right",
Software Engineering should be covered, covered early in the
curriculum, and expected of the students in all their work.
It is not adequately presented in most CS programs.
However, the argument given above sounds all too familar - it's
a parody of the argument given by education programs for the
last few decades - "We'll teach teachers to teach anything"
and of business management programs - "We'll teach managers
to manage anything."
This philosophy that has led to teachers going into elementary
school teaching with pathetic skills in English, Mathematics,
whatever. (Such as the student teacher (who is now teaching!)
that told his students to construct the past tense by adding
'ed' to words and *gave* them the examples 'swimmed' and 'runned'.)
My point is that you cannot "just teach the things they'll be
using" - you end up with truly empty courses without giving the
students any real knowledge. Operating Systems (for example) is
a valid and valuable course because it is an in depth look at
at least one complex field within computer science and because
(as has been said) it ties together a lot of otherwise esoteric
topics. I'm particularly fond of compiler courses for exactly
the same reasons.
I rarely use Calculus anymore. I constantly use the skills I
learned in my Caluculi courses. Had I been explicitedly taught
those skills devoid of their *real* application, I don't believe
I could use them as adroitly.
--
Steve Wampler
{....!arizona!naucse!sbw}crm@romeo.cs.duke.edu (Charlie Martin) (11/17/89)
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)
crm@romeo.cs.duke.edu (Charlie Martin) (11/17/89)
Bill: Could you please offer an example of a reasonable software engineering project that is not an example of a narrow application problem domain if compilers and operating systems are examples of narrow application domains? Charlie Martin (crm@cs.duke.edu,mcnc!duke!crm)
kcby@scotty.Atlanta.NCR.COM (K. C. Yakemovic) (11/17/89)
In article <7046@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: >From ofut@hubcap.clemson.edu (A. Jeff Offutt): > ... neither is it reasonable > to require people who wish to become information systems software > engineers to complete an operating systems project. Instead, > there exist domains which are reasonably uncomplicated, such as > gradesheet management, which are quite well-suited for use as a > basis for a general-purpose software engineering project. Since > the domain is simple and easily understood, the software engineering > course can focus instead upon software development processes, > < deleted list of processes... which included requirements analysis> It is my opinion that one of the greatest weaknesses we have in industry is in the *requirements analysis* area. I'll agree you can teach most of the other software engineering processes with "uncomplicated" domains. But it seems to me that learning to do requirements analysis requires a reasonably complicated domain. Especially as 'beginning' software engineers, we are not likely to work in familiar, or easly understood, domains. In many cases, our new employeer will be trying to move into areas that no one in their organization knows well. Allowing a student to learn how to deal with difficult problems could be very beneficial... a taste of the real world! I was going to say that with the limited amount of time available, perhaps the more difficult subject of requirements analysis should be taught in a separate course. However, it occurs to me that *I* have to do requirements analysis under a schedule which doesn't allow much time... so learning methods which allow it to be done quickly would also be a benefit. - kcby@Atlanta.ncr.com KC Burgess Yakemovic
crm@romeo.cs.duke.edu (Charlie Martin) (11/17/89)
In article <7057@hubcap.clemson.edu hutch%citron.cs.clemson.edu@hubcap.clemson.edu writes:
Can it still be true that most people actually believe in
the waterfall model of the life cycle?
Unfortunately, yes, Get a look at DoD 2167A or most SE texts.
There are a lot of people (some who have reviewed papers of mine) who
belive that the waterfall model IS the life cycle. Not the description,
the thing in itself.
Charlie Martin (crm@cs.duke.edu,mcnc!duke!crm) madd@world.std.com (jim frost) (11/17/89)
rsd@sei.cmu.edu (Richard S D'Ippolito) writes: >In article <7036@hubcap.clemson.edu> A. Jeff Offutt writes: >>Here's one of my ideas for a perfect software engineering project: >> An operating system. ...Another one: A compiler >Please explain how these require any engineering methods and relate to >anything that goes on in the industries that produce software-dependent >systems. Operating systems have real-life examples of how to use many of the algorithms that you see in class. Additionally, they show how to build reliability into a program, something which almost never shows up in classwork and which is absolutely necessary in the real world. Lastly, their size and complexity will force a student to deal with many of the "real world" problems that come with debugging or extending a large system. Unfortunately operating systems often have a lot of goo which is handling hardware weirdnesses, so you can loose a lot of good system design inside of a mess of trivialities. I don't think this is particularly bad (the "real world" is like that!) but it can be distracting. jim frost software tool & die madd@std.com
dar@nucleus.UUCP (Dario Alcocer) (11/17/89)
In article <7012@hubcap.clemson.edu>, billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) writes: > From dar@nucleus.UUCP (Dario Alcocer): > > I think that the technical school and high schools are the ones in the > > position to train people for the job market. > > ... The only reasonable solution is to provide at least two tracks > within the university system: a research track and a practitioner's > track. If this were combined with several other mechanisms by which > meaningful dialogue would be facilitated between the two communities, > then we would be well on our way to a much-improved system. > > > Bill Wolfe, wtwolfe@hubcap.clemson.edu > Your points are well taken. I agree with your observation that practioners and researchers do not communicate enough with each other, many new developments in computer science are probably not taken advantage of quickly because practioners many times don't share the same experiences and terminology that the researchers do, and maybe the researchers could benefit from seeing their hypotheses proven or disproven when applied to real-world applications. Relating to this, what do you think of the cooperative education system in place at the University of Waterloo? I think that a good start would be for students to get 2 or 3 years of experience, and then have 1 or 2 years of CS or CE training to help them see how theory and engineering techniques can be used to solve the same problems seen in their first 2 years more effectively. Practical experience becomes more valuable, I feel, when you have theoretical framework to able to generalize on your experience and the experience of others. In fact, I see theoretical knowledge as partly being the generalized experience of the whole. Again, thank you for sharing your ideas, and I appreciate you correcting me on some mistaken opinions I've had. Dario Alcocer dar@nucleus.mi.org
davis@community-chest.uucp (Dave Davis) (11/17/89)
In article <9759@june.cs.washington.edu> peterd@june.cs.washington.edu.cs.washington.edu (Peter C. Damron) writes: >In article <34705@regenmeister.uucp> chrisp@regenmeister.uucp (Chris Prael) writes: >>There is a basic set of disciplines to engineering. This set seems to (stuff deleted) > >I'm not sure I know what you are talking about. >Just what is this "basic set of disciplines" that engineers learn? >How does it differ from what I would call "tools and techniques"? > >Excuse my ignorance, >Peter. > First, one learns the scientific method or mindset toward the world and toward problem solving. Then, basic physics and mathematics, particularly as it relates to a specialty, e.g., circuits, materials, or structures. Meanwhile, we also learn how to solve some of the current technical problems while becoming familiar with applications of technology. It is this last component that seems to embody the bulk of the undergraduate computer scientists work, as contrasted with the engineer, with the theory of the computer science profession taught in grad. school! ====================================================================== Dave Davis ddavis@mitre.org MITRE Corp. McLean, VA
robert@isgtec.UUCP (Robert Osborne) (11/17/89)
In article <7036@hubcap.clemson.edu> ofut@hubcap.clemson.edu (A. Jeff Offutt) writes: >Here's one of my ideas for a perfect software engineering project: > An operating system. > A compiler > I went to UofWaterloo as a co-op. On my first work term I had to write (from scratch) a simple CAD/CAM system (~10000 lines in 4 months). The effect of this was threefold: 1) All of my courses suddenly ment something. I saw things that I had needed for my system and how bad (or relatively good) my own solutions were. I learned to judge for myself the relevance of what I was learning. 2) I learned about user interfaces, databases, the importance of comments and other documentation (I couldn't read my own code after 2-3 months), and some elementary design principles and their importance. 3) I learned how poorly done projects can haunt you later in life (I keep saying, if only I had that project now :-). For this reason would suggest that training for any computer programmer, should start off fairly early with such a project (perferably in groups). Then throughout the education process projects like this should be done every year. Then by the end of three or four years you would have a good programmer. I don't think that an OS and a compiler are "perfect" engineering projects although I think that they should be studied. I have seen engineering departments where they hired several community college engineering "technicians" and placed them under a VERY good professional engineer. This is usually cheaper and more successful then hiring several good engineers. I see a similiar idea being good in computing, where several programmers at a "technician" or community college level work with a GOOD computer "scientist", one who has taken courses in OS's, compiliers, design theory, etc. Of course this means that community colleges must start training programmers, so far most of the courses at colleges are "language of the week" courses or "business oriented" software courses. Rob. -- Robert A. Osborne | I take full responsibility for the opin... ...uunet!mnetor!lsuc!isgtec!robert | <HEY BUD, get off the box, it's my turn!> ...utzoo!lsuc!isgtec!robert | oops, sorry about that.
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (11/17/89)
From kcby@scotty.Atlanta.NCR.COM (K. C. Yakemovic): > It is my opinion that one of the greatest weaknesses we have in industry is > in the *requirements analysis* area. I'll agree you can teach most of the > other software engineering processes with "uncomplicated" domains. But it > seems to me that learning to do requirements analysis requires a reasonably > complicated domain. The limited time factor will probably preclude doing this in the first course; but when it *is* done (in a more advanced course), I would think that having the students do requirements analysis by looking up the domain in a textbook someplace (as is possible with operating systems and compilers) is unlikely to be of maximum value; instead, a domain should be selected from the "real world", for which little advance documentation is available, and in which real users will have to be satisfied. Local industries would probably be very happy to have some real problems solved for them for free... they would be an excellent source for "real" projects. Bill Wolfe, wtwolfe@hubcap.clemson.edu
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (11/17/89)
From dar@nucleus.UUCP (Dario Alcocer): > Relating to this, what do you think of the cooperative education system in > place at the University of Waterloo? I think that a good start would be for > students to get 2 or 3 years of experience, and then have 1 or 2 years of CS > or CE training to help them see how theory and engineering techniques can be > used to solve the same problems seen in their first 2 years more effectively. The cooperative education movement is gaining strength here in the US, but obviously Canada, at least at Waterloo, is far ahead in that area. There is a great need to integrate industry and academia, not only in the initial phases of professional training, but throughout the entire career path. Universities, at least in the US, are missing out on a big opportunity to provide continuing education (and also appropriate documentation which would be transferable between employers) to professionals over the entire course of their careers, rather than simply providing services only at the beginning of a career, but we presently have a very long way to go before this could be achieved. Bill Wolfe, wtwolfe@hubcap.clemson.edu
sullivan@aqdata.uucp (Michael T. Sullivan) (11/17/89)
Here's my two cents: There should be separate Computer Science and Software Engineering degrees. Period. -- Michael Sullivan uunet!jarthur.uucp!aqdata!sullivan aQdata, Inc. San Dimas, CA
misu_cif@uhura.cc.rochester.edu (What`s in a name?) (11/17/89)
In article <1989Nov17.015008.2026@aqdata.uucp> sullivan@aqdata.uucp (Michael T. Sullivan) writes: >Here's my two cents: There should be separate Computer Science and >Software Engineering degrees. Period. Amen. >-- >Michael Sullivan uunet!jarthur.uucp!aqdata!sullivan >aQdata, Inc. >San Dimas, CA -- Mic3hael Sullivan, Society for the Incurably Pompous -*-*-*-*- English -- learn it -- use it -- it's YOUR language.
rsd@sei.cmu.edu (Richard S D'Ippolito) (11/17/89)
In article <1054@scotty.Atlanta.NCR.COM> K. C. Yakemovic writes: >It is my opinion that one of the greatest weaknesses we have in industry is >in the *requirements analysis* [RA] area. ... >I was going to say that with the limited amount of time available, perhaps >the more difficult subject of requirements analysis should be taught in a >separate course. There is still no real consensus in the industry for what requirements are and what requirements analysis is. There are IEEE definitions, but they are as poor as most of the rest of the definitions of software terms. They make very little distinction between requirements and specifications. What do you mean by requirements, and what are examples of those things that you would like taught? Is RA part of the design process? Who does it? >I'll agree you can teach most of the >other software engineering processes with "uncomplicated" domains. But it >seems to me that learning to do requirements analysis requires a reasonably >complicated domain. What are all of the "software engineering processes", and what do you mean by a complicated domain? Rich -- When you can measure what you are speaking about, and express it in numbers, you know something about it. Lord Kelvin rsd@sei.cmu.edu -----------------------------------------------------------------------------
reggie@dinsdale.nm.paradyne.com (George W. Leach) (11/17/89)
In article <1814@naucse.UUCP> sbw@naucse.UUCP (Steve Wampler) writes: [stuff deleted] >My point is that you cannot "just teach the things they'll be >using" - you end up with truly empty courses without giving the >students any real knowledge. The things they will be using will change over time. The concepts that are taught can be applied much longer. >Operating Systems (for example) is >a valid and valuable course because it is an in depth look at >at least one complex field within computer science and because >(as has been said) it ties together a lot of otherwise esoteric >topics. I'm particularly fond of compiler courses for exactly >the same reasons. These kinds of courses provide examples of applying computer science theory to real applications. They just don't tie together esoteric topics but demonstrate how applying knowledge gaining in other CS courses to real problems. Many apsects of compiler design can be applied to other areas. Too often folks go off and blindly build systems. If they had an adquate background in other areas, they could leverage off of previous experiences. Even within CS we are guilty of this. How many folks have run off and built distributed operating systems without looking into what work has been done in distributed databases? >I rarely use Calculus anymore. I constantly use the skills I >learned in my Caluculi courses. Had I been explicitedly taught >those skills devoid of their *real* application, I don't believe >I could use them as adroitly. A college education will further the ability to learn, by showing us how to acquire and apply knowledge. This is something you just don't get in a trade school. George W. Leach AT&T Paradyne (uunet|att)!pdn!reggie Mail stop LG-133 Phone: 1-813-530-2376 P.O. Box 2826 FAX: 1-813-530-8224 Largo, FL 34649-2826 USA
madd@world.std.com (jim frost) (11/18/89)
robert@isgtec.UUCP (Robert Osborne) writes: >I have seen engineering departments where they hired several community >college engineering "technicians" and placed them under a VERY good >professional engineer. [...] I see a similiar idea being good in >computing, where several programmers at a "technician" or community >college level work with a GOOD computer "scientist", one who has taken >courses in OS's, compiliers, design theory, etc. This is an excellent idea, for a variety of reasons. First, it familiarizes students with real-life concepts -- complexity, schedule, communication, and other aspects of real-life that are generally nonexistent in academic environments. Second, students who are recently out of theoretical courses might be able to give an influx of new ideas or ideas which more jaded programmers have forgotten. Much research goes on that real-world programmers miss, often to the detriment of the general community. Third, the students will become excellent targets for hire after graduation. They already have the experience and will be familiar with the work in at least one environment. As for the relationship between a technician and a scientist, I feel they should be identical, because the sum of the two is better than the individuals. Realistically, however, "There's the way things should be, and the way things are." Best we can hope for is to improve our hit rate :-). Happy hacking, jim frost software tool & die madd@std.com
madd@world.std.com (jim frost) (11/18/89)
sullivan@aqdata.uucp (Michael T. Sullivan) writes: >Here's my two cents: There should be separate Computer Science and >Software Engineering degrees. Period. Nope. While each stands on its own, those with experience in both are much more effective than those with experience in only one. About equal percentages would be good, but many institutions focus primarily on one or the other (seems to me that most are CS-oriented without much of the practicality of SE). jim frost software tool & die madd@std.com
dalamb@qucis.queensu.CA (David Lamb) (11/18/89)
David Parnas, a fairly well-known name in Software Engineering, wrote a report last winter about "Education for Computing Professionals", which outlines his opinions about what undergraduate education practitioners should have. It includes very little of conventional computer science. I don't have my copy handy and am too lazy to find it right now, but I can recall a strong emphasis on basic hard science (physics and chemistry); mathematics (including a couple of terms of calculus, which a lot of CS programs de-emphasize); things from engineering programs typically ignored in CS programs like control theory and signal processing. He also doesn't call for a lot of currently hot "Software Engineering" topics, either. I think we have some copies left; if you want one, send me a postal address and I'll try to arrange to send you one. Parnas may be intending to publish it more widely; I'm not sure, and he's out of town right now. David Alex Lamb Department of Computing and Information Science Queen's University Kingston, Ontario, Canada K7L 3N6 (613) 545-6067 ARPA Internet: David.Lamb@cs.cmu.edu dalamb@qucis.queensu.ca uucp: ...!utzoo!utcsri!qucis!dalamb
chrisp@regenmeister.uucp (Chris Prael) (11/18/89)
From article <1054@scotty.Atlanta.NCR.COM>, by kcby@scotty.Atlanta.NCR.COM (K. C. Yakemovic): > But it > seems to me that learning to do requirements analysis requires a reasonably > complicated domain. Eventually, yes. But, as my violin teacher used to say to me, first we learn how to walk, then we can learn how to run. The main issue is that computing students do not seem to be trained to analize requirements at all. Chris Prael
chrisp@regenmeister.uucp (Chris Prael) (11/18/89)
From article <211@isgtec.UUCP>, by robert@isgtec.UUCP (Robert Osborne): > I see a similiar idea being good in > computing, where several programmers at a "technician" or community > college level work with a GOOD computer "scientist", one who has taken > courses in OS's, compiliers, design theory, etc. Of course this means > that community colleges must start training programmers, so far most > of the courses at colleges are "language of the week" courses or > "business oriented" software courses. This idea has been tried. About 13 years ago a lot of companies went very big for the "chief programmer" style of development group set up. It went out of style very quickly when everyone started to us C to write code. The style, or model, was no longer fit the circumstances. There is another problem with this solution. If you understand how an engineer works, it quickly becomes obvious that a computer "scientist" usually functions as a technician, not as an engineer. This is not an effective way to structure a programming team. Chris Prael
mjl@cs.rit.edu (11/19/89)
In article <7091@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: > ... a domain should be selected from the > "real world", for which little advance documentation is available, > and in which real users will have to be satisfied. Local industries > would probably be very happy to have some real problems solved for > them for free... they would be an excellent source for "real" projects. > > > Bill Wolfe, wtwolfe@hubcap.clemson.edu Well, local industries usually don't believe in free lunches, and have even lower regard for free software. But a variant on this has been used at RIT for years in Programming Systems Workshop (a senior level course). We scout around for projects on campus that are desirable but not critical. Teams then meet with the "contracting agency" (often a faculty member or department chair), work out the requirements, do the design, and, with any luck, deliver at least a prototype. That's about all one can expect in a 10 week term. Of course, the fact that all of our students will have completed at least 2 of their 4 co-op quarters by the time they take PSW means they have some familiarity with the industrial and commercial sectors, so they're a bit more savvy (perhaps cynical) than most students at this point in their education. UNPAID PROMOTIONAL ANNOUNCEMENT Hire co-ops -- help start students on their way to productive, creative, and fulfilling professional careers! Mike Lutz Mike Lutz Rochester Institute of Technology, Rochester NY UUCP: {rutgers,cornell}!rochester!rit!mjl INTERNET: mjlics@ultb.isc.rit.edu
munck@chance.uucp (Robert Munck) (11/19/89)
In article <4992@ae.sei.cmu.edu> rsd@sei.cmu.edu (Richard S D'Ippolito) writes: >In article <1054@scotty.Atlanta.NCR.COM> K. C. Yakemovic writes: > >>It is my opinion that one of the greatest weaknesses we have in industry is >>in the *requirements analysis* [RA] area. ... > >What do you mean by requirements, and what are examples of those things that >you would like taught? Is RA part of the design process? Who does it? > In the SADT requirements analysis methodology (Ross, et.al.), a requirements specification is said to be a comprehensive statement of the changes necessary to transform the current situation into the desired situation. Such a statement must include detailed descriptions of both the current and desired situations to be understandable. In SADT, each of these descriptions consists of structured (that is, containing several levels of overview/detail) models with various viewpoints, contexts, and purposes. Among the topics discussed in the full 120-hour SADT course are: o Interviewing application experts who may have no computer background; o Writing specs that are understandable by such experts; o Dealing with organizational politics; o Teamwork based on courtesy, individual strengths, shared goals; and o Striking a balance between abstractness and early design. I've taught both at a university and in commercial/military institutions; IMO, most of the material in a requirements analysis course is so different from the "flavor" of an academic course that it could not be taught to anyone without five years or so of "real-world experience." -- Bob <Munck@MITRE.ORG>, linus!munck.UUCP -- MS Z676, MITRE Corporation, McLean, VA 22120 -- 703/883-6688
gordon@banyan.UUCP (Gordon Lee@Eng@Banyan) (11/20/89)
First off, I'd like to apologize for the goof up on my last posting, I was having a problem with the posting software and didn't realize that every failed attempt to send was reappending the article to dead.article. I was trying to resend dead.article you see, but anyway... In article <4992@ae.sei.cmu.edu> rsd@sei.cmu.edu (Richard S D'Ippolito) writes: >In article <1054@scotty.Atlanta.NCR.COM> K. C. Yakemovic writes: > >>It is my opinion that one of the greatest weaknesses we have in industry is >>in the *requirements analysis* [RA] area. ... >>I was going to say that with the limited amount of time available, perhaps >>the more difficult subject of requirements analysis should be taught in a >>separate course. > >There is still no real consensus in the industry for what requirements >are and what requirements analysis is. There are IEEE definitions, but they >are as poor as most of the rest of the definitions of software terms. They >make very little distinction between requirements and specifications. > Given the absence of an industry consensus on the definition of Req Analysis, is there a well-known list of proposed definitions that have been set forward as likely candidates ? In article <4992@ae.sei.cmu.edu> rsd@sei.cmu.edu (Richard S D'Ippolito) writes: >What do you mean by requirements, and what are examples of those things that >you would like taught? Is RA part of the design process? Who does it? I'm relatively new to the debate, but here's my 2 cent definition... For me, Req Analysis is the process of defining the problem. There are two entities, be they two distinct people, two distinct groups of people, or maybe both entities are one person. One entity has (or thinks he has) a problem to be solved, call him the "user". The other entity is called on or acts to solve the problem through some computational model, call him the "engineer". Req Analysis is the process that these two entities go through to identify the domain of the problem, research the domain, define the bounds of the problem, and then finally produce some form of document which itemizes knowledge collected, and presents some model of the problem. It would also contain references to supporting documents which were used during the research phase. The reason I would guess that even IEEE has trouble seperating this process from the process of developing specifications is that in actual practice most engineers do both at the same time. That is they tend to model the problem in terms of a potential solution. So what they end up with is not what anyone would call a model of the problem, but a specification of the solution. I think it is instinctual to approach problem solving by: 1. rapidly trying a variety of solutions "in one's head" 2. choosing the one that is perceived to be the closest 3. refining this solution to make it fit So for most people, Req Analysis is reduced to a simple exercise in comparative judgement. How many have been frustrated by or perhaps taken advantage of the fact that a bad Human Resource Department will tend to match Job Req's and resumes by keying off buzzwords. But most people would agree that this is a very limited way of thinking. It is limited by the thinker's knowledge of potential solutions and by how much of the problem domain's complexity the thinker can "see" let alone comprehend. Remember an earlier article: In article <4969@ae.sei.cmu.edu> Richard S D'Ippolito writes: >This is right on the mark! From Tomas Maldonado, "The Aspen Papers": > > "Therefore we must say that for the moment the most distinctive > characteristic of man is not his capactiy to solve problems but > more his capacity to set them." That's a great quote. I take "problem-solving" in Tomas' observation to mean the exercise in comparative judgement I described above. I see one's capacity to "set the problem" as defined by: - one's ability to recognize the limits of one's knowledge of the bounds of the problem domain and the range of potential solutions. - one's ability (and motivation) to expand one's knowledge in those two areas. In article <4992@ae.sei.cmu.edu> rsd@sei.cmu.edu (Richard S D'Ippolito) writes: >In article <1054@scotty.Atlanta.NCR.COM> K. C. Yakemovic writes: >>I'll agree you can teach most of the >>other software engineering processes with "uncomplicated" domains. But it >>seems to me that learning to do requirements analysis requires a reasonably >>complicated domain. > >What are all of the "software engineering processes", and what do you mean >by a complicated domain? In light of what I have said above, I'd like to suggest that "complicated domain" is a relative term. I think all domains are complicated, the existing body of AI research is a testimony to the complexity of even the most mundane of domains. Instead of measuring the complexity of the domain, we should measure an individual's knowledge of the domain and past experience with solutions to problems presented by the domain. Richard, you presented a couple of interesting quotes in an earlier article, D. Schoen, "The Reflective Practicioner" Tomas Maldonado, "The Aspen Papers" I only first heard about the Software Engineering Institute last week when I started reading a friend's back issues of CACM. I was wondering if you or the SEI as a whole have a recommended reading list of some form that you could share. I'd like to do some reading on issues concerning the state of SE as a discipline, starting with a general background on who's who, what ideas are current, what ideas have fallen out of practice, etc, etc... If you could mail to me or perhaps post to the net, as you see fit. For that matter, if anyone has any reading list recommendations they would like to suggest, I would be interested in hearing of them. I am looking first for general background info, and then also anything considered seminal, the "must-reads" which get the most attention. thanks -- ============================================================================= Gordon Lee gordon@banyan.com or gordon@bu-it.bu.edu Banyan Systems, Inc. Westboro, MA "Pay no attention to that man behind the keyboard..."
dar@nucleus.UUCP (Dario Alcocer) (11/21/89)
In article <603@banyan.UUCP>, gordon@banyan.UUCP (Gordon Lee@Eng@Banyan) writes: > For that matter, if anyone has any reading list recommendations they > would like to suggest, I would be interested in hearing of them. > I am looking first for general background info, and then also > anything considered seminal, the "must-reads" which get the most attention. > I second that! I came out of school with a BA in Math/CS, and I must admit they didn't teach us much about how to implement many concepts taught us (after all, it was a CS degree, and I knew more or less I'd probably have to learn implementation techinques out in the field). Anyway, I would be interested in seeing a Software Engineering reading list so that I can learn more about it. Hasta... dario. +==================================================================+ | + | | Dario Alcocer (San Diego, CA) | Internet......dar@nucleus.mi.org | | via Nucleus | phone...............619-450-1667 | | + | +==================================================================+
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (11/21/89)
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. > 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. > 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. > 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
madd@world.std.com (jim frost) (11/22/89)
dar@nucleus.UUCP (Dario Alcocer) writes: >In article <603@banyan.UUCP>, gordon@banyan.UUCP (Gordon Lee@Eng@Banyan) writes: >> if anyone has any reading list recommendations they >> would like to suggest, I would be interested in hearing of them. >> I am looking first for general background info, and then also >> anything considered seminal, the "must-reads" which get the most attention. >I second that! I haven't finished this thread so I'm not sure if this has been covered, but if you haven't read Brooks' _Mythical Man Month_ you really, really should. It's number one on my required reading list. jim frost software tool & die madd@std.com
madd@world.std.com (jim frost) (11/22/89)
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) writes: >From crm@romeo.cs.duke.edu (Charlie Martin): >> 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. In my (limited) classroom experience, roughly half of the required courses were irrelevant to either real life or theoretical computer science. There are a lot of free hours if you kill those courses. Those courses are easy to identify. Find the student that spends the most time on the machine or has a huge personally written source directory. S/he'll probably work for the CS department. Ask him/her what courses were useless. Then find a couple of people with a MA/CS double major who have excellent GPAs and ask the same question. This will give you a feel for which courses were practically-oriented, which were theoretically-oriented, and which did little of either. I believe you'll find that there's a high occurrence of courses which don't really teach anything at all (although their titles may suggest that they do). Often a course which should be very valuable (eg an algorithms course) is not because a professor spends almost the whole course talking about his particular pet algorithm. Worse than that are the courses where the professor can't speak english (or the native language) well enough to teach the students, since there's no way they're going to get anything out of the course. I had far too many of both kinds of courses. Eliminating or improving them would go a long way towards improving education. I'll tell you right now that I know this won't work. Politics, bureacracy, and tenure will screw it up. But it's a good idea. >> 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. OS is never irrelevant if the student isn't going to be a theoretician. If the student must work in the real world, s/he will need a lot of the concepts which are discussed AND IMPLEMENTED in an OS course. I wouldn't hire someone who didn't have such experience (or similar experience with compilers) unless they've been in the real world for quite some time. >> 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. Name another standard course (excepting compilers) which makes extensive use of lists and list processing. Algorithms SHOULD, but in practice most algorithms courses are almost purely theoretical (lots of funny-looking symbols but not a for() in the whole place :-). Additionally, an operating system deals with algorithmic complexity (it shows up early on when trying to do things like memory-fitting or scheduling) which are virtually never dealt with realistically in academic courses but are critical for many real-life applications. They teach common techniques for dealing with space/time tradeoffs. They deal with asynchronous event handling which shows up in VERY few other courses but is commonplace in real-life. They teach heavy modularization (or they should) due to the easy segregation of operating system subsystems. And they're large enough to give students an idea of what they're going to have to deal with when they walk out the door. If you can find me some other topic which deals with all or most of these topics, then I'll believe you. > 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. Of course not. But they're only a small subset of the topics at hand. >> (3) Operating systems offer the first chance in most cases to introduce >> things like mutual exclusion and record management (reader-writer >> problems). > This is simply another > attempt to claim that operating systems are good because of > incidental side effects which should instead be taken directly. Operating systems courses are good because they deal with solving real-life problems, LOTS of them. Most of the problems you'll run into in the "real world". And they deal with them all in one place, so students can see how different problems -- all of which can interact (and DO in the "real world") -- can be handled, something which you'll miss if you have separate courses on each individual topic. jim frost software tool & die madd@std.com
reggie@dinsdale.nm.paradyne.com (George W. Leach) (11/22/89)
In article <1989Nov21.165024.2840@world.std.com> madd@world.std.com (jim frost) writes: >I haven't finished this thread so I'm not sure if this has been >covered, but if you haven't read Brooks' _Mythical Man Month_ you >really, really should. It's number one on my required reading list. Other relevant books: (1) Programming in the large: Gerald M. Weinberg, The Psychology of Computer Programming, Van Nostrand Reinhold, 1971. (2) Programming in the small: Brian W. Kernighan, and P.J. Plauger, The Elements of Programming Style, Second Edition, McGraw-Hill, 1978. Jon Louis Bentley, Writing Efficient Programs, Prentice-Hall, 1982. Jon Bentley, Programming Pearls, Addison-Wesley, 1986. Jon Bentley, More Programming Pearls, Addison-Wesley, 1988. Brian W. Kernighan, and P.J. Plauger, Software Tools, Addison-Wesley, 1976. George W. Leach AT&T Paradyne (uunet|att)!pdn!reggie Mail stop LG-133 Phone: 1-813-530-2376 P.O. Box 2826 FAX: 1-813-530-8224 Largo, FL 34649-2826 USA
rsd@sei.cmu.edu (Richard S D'Ippolito) (11/23/89)
In article <1989Nov21.172751.3078@world.std.com> jim frost writes: >Operating systems courses are good because they deal with solving >real-life problems, LOTS of them. Implementation problems. Engineering is about setting problems, not solving them. Still no sale. An good instructor might choose to use OS as a vehicle of teaching software engineering, but using it as the sole example of an engineering problem would be wasteful and inefficient. Besides, it lacks a wide systems perspective. Rich -- When you can measure what you are speaking about, and express it in numbers, you know something about it. Lord Kelvin rsd@sei.cmu.edu -----------------------------------------------------------------------------
crm@romeo.cs.duke.edu (Charlie Martin) (11/23/89)
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)
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (11/26/89)
From madd@world.std.com (jim frost): >>> 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. > > Name another standard course (excepting compilers) which makes > extensive use of lists and list processing. The course on data structures should give the student a basic understanding of list ADTs as well as many others; applying this or any other data abstraction must be left to application courses, the exact nature of which will be student-specific. > Additionally, an operating system deals with algorithmic complexity > (it shows up early on when trying to do things like memory-fitting or > scheduling) which are virtually never dealt with realistically in > academic courses but are critical for many real-life applications. I would strongly disagree with this; I took a course in algorithm design and analysis as an undergraduate, and I consider it to have been the single most valuable course in the entire curriculum. > They teach common techniques for dealing with space/time tradeoffs. The data structures course (if good) will cover this quite thoroughly. > They deal with asynchronous event handling which shows up in VERY few > other courses but is commonplace in real-life. And should be equally commonplace in CS programs. One of the major practical problems associated with eliminating OS requirements is that, generally speaking, advanced courses in concurrent software development are not yet being offered -- I consider this to be a rather major shortcoming of the current CS educational system. > They teach heavy modularization (or they should) due to the easy > segregation of operating system subsystems. Appropriately taught in the first software engineering course, along with the different levels of coupling and cohesion. > If you can find me some other topic which deals with all or most of > these topics, then I'll believe you. How about some other course structure? > Operating systems courses are good because they deal with solving > real-life problems, LOTS of them. Most of the problems you'll run > into in the "real world". And they deal with them all in one place, > so students can see how different problems -- all of which can > interact (and DO in the "real world") -- can be handled, something > which you'll miss if you have separate courses on each individual > topic. As you correctly point out, operating systems are an example of an application domain in which many software development problems can realistically interact. My contention is that there are many such application domains, and it would behoove us to present the student with software development problems which are relevant to the problem domain(s) in which the student intends to specialize. In this way, we will give practical reinforcement to the introductory material on software development AND practical reinforcement of the introductory material for a relevant application domain; I submit that the combination has a strong synergistic effect on the student. The result is a strong positive (vs. negative) motivation, a very high transfer and retention rate, and a much more enjoyable experience on both sides of the educational interface. Bill Wolfe, wtwolfe@hubcap.clemson.edu
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (11/26/89)
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
PAAAAAR@CALSTATE.BITNET (11/28/89)
on another thread JOHNKAL@YALEVM.BITNET wrote: >At Yale, where I am developing a system for the library, I have been >trying to teach folks about the project life-cycle. I have lots of >books about writing program specs., but nothing about how to develop and >write user requirements. Not one of the books on my shelf offers an >example of user requirements. Most books on project management seem to >focus on writing good code, and work under the assumption that the >program will be what the user wants. Proto-typing can be very costly, >and still may not solve the problem. Comments?? >John W. Kalkbrenner >Sr. Research Programmer >Yale University >johnkal@yalevm Analysis is not taught in the 'standard'/CSAB CS degree. I've detected a feeling that 'analysis' = 'systems analysis' and is part of an MBA. Thus few CS text books cover it. I am trying to write one however. I've argued for more analysis in the new "computing core curriculum" with minimal success. The IEEE Glossary includes Requirements Analysis as a part of Software Engineering. The ANSI/IEEE standard (830-1984) for Software Requirements Specification (SRS) gives prototype contents lists (pp18, 23,24) and discusse s what properties a "good" SRS has. It explicitly (in section 1.1) states that the standard is not suitable for "rapid prototyping" or maintenance. The standard (para 5.1.3.1) states that mathematics is useful for special areas such as "navigation, linear programming, ...". Para 5.1.3.2 describes "Functional Models" and gives an example - which is a finite state machine. The formal approaches developed in Europe and mandated by the UK Ministry of Defense (VDM/Z/CSP/...) go further and propose to use bespoke mathematics to express requirements - examples include CICS, banking, libraries, phone books , elevators and so on. My research is exploring the limits of using discrete mathematics (logic, sets, relations, functions, abstract algebras, ..., languages and automata theory ) to express requirements. I am developing (oh, so slowly) a practical language for formal documentation called PINAPL ( PINAPL = PINAPL Is Not A Programming Language). Most requirements can be expressed by specially created formal models using the discrete math and theory found in currant CS degrees. The idea that theory is useful is heretical! Even so the creative use of Maths in Requirements Analysis and Domain Analysis can and should be taught as part of Software Engineering. ------------------------------------------------------------------------- Richard J. Botting, Department of computer science, California State University, San Bernardino, 5500 State University Parkway, San Bernardino CA 92407 PAAAAAR@CCS.CSUSCC.CALSTATE paaaaar@calstate.bitnet PAAAAAR%CALSTATE.BITNET@CUNYVM.CUNY.EDU --------------------------------------------------------------------------- Even Users have a right to pursue happiness ---------------------------------------------------------------------------
warren@psueea.uucp (Warren Harrison) (11/30/89)
This article had so many follow ups I got lost as to who said what, but I think this is attributed to Bill Wolfe: > 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. It is the rare student indeed who *knows* what will be irrelevant and what will be relevant in their career. A good university education should provide the student with the breadth that will allow exploration outside a narrowly defined specialty. For example, my undergrad degree was in Accounting. Luckily I was able (required) to take other courses which I thought at the time were irrelevant. I found these to be some of the most valuable courses I ever had, and prepared me well for switching carrers (I'm now trying to be a Computer Scientist). If you want specialization to the degree many people are suggesting in this newsgroup, you're much better off going to a trade school and learning the exact skills you perceive you'll need for the future. If you currently are a practicing software engineer and want specific skills that *you* think will help you, there is no lack of very good seminar/workshop road shows that are bound to visit your city at least once a year - I have taught several of them myself. They are certainly not meant to be a substitute for a university education, and vice-versa. Warren Harrison CSNET: warren@cs.pdx.edu Department of Computer Science UUCP: {ucbvax,decvax}!tektronix!psueea!warren Portland State University Internet: warren%cs.pdx.edu@relay.cs.net Portland, OR 97207-0751
ge@kunivv1.sci.kun.nl (Ge' Weijers) (12/01/89)
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) writes: > 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. I can't agree with that one. It is true that you can describe the semantics of operations without using internal algorithms. But to analyse performance of file systems you need to know quite a lot about them. And in DP applications performance is critical. I recently heard a story about a big database that was split into a number of smaller parts, one for each of the client organisations of the database. This seemed a good decision, but the OS did not support multiple processes sharing code. Swapping bogged down the system critically, because there was much less locality of references on the system. OS theory (not writing one) is a necessary part of CS eduaction. After your students have acquired this theory you might as well use it as a project in Software Engineering. (An OS course should NOT be a 'lets build a mini Unix using traditional algorithms' course). > Bill Wolfe, wtwolfe@hubcap.clemson.edu Ge' Weijers, ge@cs.kun.nl Ge' Weijers Internet/UUCP: ge@cs.kun.nl Faculty of Mathematics and Computer Science, (uunet.uu.net!cs.kun.nl!ge) University of Nijmegen, Toernooiveld 1 6525 ED Nijmegen, the Netherlands tel. +3180612483 (UTC-2)
crm@romeo.cs.duke.edu (Charlie Martin) (12/01/89)
In article <7184@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: >> 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. > Hmmm.... I think I am beginning to see something here. Was the course you took largely directed toward the internals of the blah operating system? (I can easily imagine one being done this way... in fact, now that I think of it, the old old course I took ca. 1974 was built that way.) If so, or if it were heavily weighted that direction, then I begin to understand your point. I think. I counld go into it at great length, but I think the point is that I also agree that a course that heavily emphsizes internals of a particular operating system is not a good choice, and might not be useful. In my opinion, all such courses (OS, lnguages, etc) ought to be taught in an OS-independent manner. I think I'll hold further comments until I know more about he sort of course you've been arguing on the basis of. >> 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. > I dunno, Bill. Maybe the market is that way now, but if so, it doesn't look like it from where I am sitting now. You're absolutely right that the market for IS stuff is much broader than OS, right now and likely in the future. (One of my major complaints about the program here at Duke is that students learn about tree algorithms but not about master-file update programs. These are of course meant to be exemplar of classes of problems and solutions.) I don't doubt that you can go to a bank or some such and do IS for the next umpteen years, and if you like those programs then great. But my own experience has been this: - I started doing purest MIS in 1969. - I also got into formal methods in 1969 (with Dijkstra's book) - I moved to another MIS shop in 1978 - they asked me to do graphics in FORTRAN - I liked doing graphics in FORTRAN - I moved to a defense contractor in 1979 - I built not one but two small operating systems - I worked on an assembler - I did hard real-time - I did field maintenance and training, as well as hard real-time - I did a reporting program for returning collected data - I did human interfaces, and then human interface research. - I came to grad school - I did software engineering, formal stuff, programming languages - I did lots of math, lots of EE, (for a computer person) lots of physiology - I am picking up lots of formal systems work and trusted systems work My point here is that every time I changed "fields" I did so because there was an intersting problem to approach, I thought it would be fun, and I had sufficient general background to work on it. If I had been schooled as you suggest, many of these choices would have been limited; the OS classes I took encoded much of the background I had for reeal-time stuff, for the OSes, and also much of the file-system understanding I needed for MIS programs. Even if you "know" you're going to go do IS immediately, and "know" you won't stray, how do you "know" that conditions won't change? > 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. I think our diffference here is what is or isn't relevant; there is the other problem of how to fit it into 4 years, which may not be soluable. > > 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. Sure, sure. My point was exactly that: that SE isn't EVERYTHING (it's the ONLY thing.. ahem) but that there must be a collection of things that characterize software engineering as a field or topic if it is indeed a field or topic. > > Oh, please, I'm exhausted!! Can we discuss this in a week or three? > > 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!!! :-) :-) :-) Agreed. I should be finishing this dissertation, anyway. Charlie Martin (crm@cs.duke.edu,mcnc!duke!crm)
spf@cbnewsl.ATT.COM (Steve Frysinger of Blue Feather Farm) (12/02/89)
From article <16283@duke.cs.duke.edu>, by crm@romeo.cs.duke.edu (Charlie Martin): > In article <7184@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: > a course that heavily emphsizes internals of a > particular operating system is not a good choice, and might not be > useful. In my opinion, all such courses (OS, lnguages, etc) ought to be > taught in an OS-independent manner. I teach an undergrad OS course in exactly this way, and refer to specific systems only as illustrations and only in contrast with each other (e.g. memory management on VMS and old-Unix, both on a Vax, help to show how an OS really shapes the machine). I wish the course had a lab, because OS pieces are good engineering projects (a simulated memory-manager makes a good lab study in linked lists, &c). Further, WRITING a scheduler can help a student learn about what it does. But as far as undergrad OS is concerned, a required intro course should be about principles, not a specific implementation; a course on "Sears DieHard/OS" or whatever should be elective (and maybe not for credit). Steve Frysinger
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (12/03/89)
From crm@romeo.cs.duke.edu (Charlie Martin): > Hmmm.... I think I am beginning to see something here. Was the course > you took largely directed toward the internals of the blah operating > system? My personal experience with OS courses consists of: 1) Independent study - I read a few textbooks on my own to satisfy my own curiosity. Having done this, I decided that it was a highly specialized and utterly boring field, and lost all interest. 2) Undergrad study - compelled to take a course which involved an overview of compilers and operating systems. Boring and a waste of my time and money, but I needed the degree. 3) Graduate study - compelled to satisfy a requirement (not clearly expressed in the material I received before enrolling) that I have a course in Operating Systems Implementation. I was so infuriated by the prospect that the department decided to permit me to gain credit for the course by examination. Another total waste of time, but again I needed the degree. > I don't doubt that you can go to a bank or some such and do IS for the > next umpteen years, and if you like those programs then great. We agree completely. But apparently this route is not permitted by those who seek to dictate what will be studied. > My point here is that every time I changed "fields" I did so because > there was an intersting problem to approach, I thought it would be fun, > and I had sufficient general background to work on it. If I was interested in being a generalist, perhaps I *would* decide to take OS classes and the like. That should be MY decision. > Even if you "know" you're going to go do IS immediately, and "know" you > won't stray, how do you "know" that conditions won't change? I can't prove that I will never decide to enter another field. But I know as a fact that if I decided I wanted to be a genetic engineer, I would have to undergo large quantities of retraining. This is viewed as entirely natural and desirable. If I do not wish to enter a different field of endeavor, then I should not have to endure irrelevant coursework. If I do, then there is a change in the set of material which is considered relevant, and I will then go out and obtain a complete understanding of this new material. THIS is how the system should operate! Bill Wolfe, wtwolfe@hubcap.clemson.edu
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (12/03/89)
From ge@kunivv1.sci.kun.nl (Ge' Weijers): >> Enough to understand how to use the tool, and no more. > % I can't agree with that one. It is true that you can describe the semantics % of operations without using internal algorithms. But to analyse performance % of file systems you need to know quite a lot about them. And in DP % applications performance is critical. I recently heard a story about % a big database that was split into a number of smaller parts, one for % each of the client organisations of the database. This seemed a good % decision, but the OS did not support multiple processes sharing code. % Swapping bogged down the system critically, because there was much less % locality of references on the system. Performance should be documented by the OS vendor. Compilers should document their performance with respect to the OSs they run under. If this is not done, then the information can be developed by specialists in performance issues. There is no need for application developers to do the work of the vendors or or the performance issues analysts. I repeat: Enough to understand how to use the tool, and no more. It may well be necessary to read and analyze tool performance data in order to use a tool, but this in no way implies that one should have to understand the internal details. Bill Wolfe, wtwolfe@hubcap.clemson.edu
crm@romeo.cs.duke.edu (Charlie Martin) (12/04/89)
In article <7289@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: > My personal experience with OS courses consists of: > > 1) Independent study - I read a few textbooks on my own to satisfy my > own curiosity. Having done this, I decided that it was a highly > specialized and utterly boring field, and lost all interest. > > 2) Undergrad study - compelled to take a course which involved > an overview of compilers and operating systems. Boring and > a waste of my time and money, but I needed the degree. > > 3) Graduate study - compelled to satisfy a requirement (not > clearly expressed in the material I received before enrolling) > that I have a course in Operating Systems Implementation. > I was so infuriated by the prospect that the department > decided to permit me to gain credit for the course by > examination. Another total waste of time, but again I > needed the degree. > In other words, you objected so much to what you thought was going to be in the operating systems courses that you've avoided taking any of them, and now feel that qualifies you to determine that it is unnecessary? On the other hand, It seems you've agreed at various points that the things like concurrent programming, resources, and file system architectures are okay.... uh, Bill, have you ever considered going into politics? As for the rest of the message, well -- there has been a debate on for a very long time about whether a university should "educate" or "train", which is buzzwordery for "Should a university equip people to reason, understand, and learn new things, or should a university teach people to become useful code jocks instantly on exiting school?" I enjoy getting an education for its own sake and I'm sometimes a little anxious to get out of school so I can get on with getting educated. On that account, I may be biased. On the other hand, I always thought I landed out a ways into the "training spectrum", to the extent that it appeared to me that schools should at least be preparing bright young engineers for what they would actually do to the extent that it would require decent knowledge of english, and some understanding that writing compilers is not what most people do in the first job out of school. It probably does me good to find that I'm not nearly as extreme as I thought. Rather than go through the whole debate again, I think I should note that this debate exists; a little reading around should get you into the thick of it, if you're of a mind to do so. I do think you're wildly wrong. In any case, the program you describe is like the Associate's Degree course I took years and years ago; taught me to be a pretty good COBOL programmer, taught me to write OS/360 JCL. Other than a couple of years of $14--$20 K jobs (this was some time ago, not bad money then) it was damned little use. Don't bother to answer me now; just remember. Ten years from now, I'll bet a fancy dinner that you'll be glad you did get what theory you got, and sorry you didn't get an OS course when you could have. Charlie Martin (crm@cs.duke.edu,mcnc!duke!crm)
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (12/04/89)
From crm@romeo.cs.duke.edu (Charlie Martin): > In other words, you objected so much to what you thought was going to be > in the operating systems courses that you've avoided taking any of them, > and now feel that qualifies you to determine that it is unnecessary? Not exactly. Notice that I had already read several textbooks on the subject before taking any formal coursework. > On the other hand, It seems you've agreed at various points that the > things like concurrent programming, resources, and file system > architectures are okay.... Again, not exactly. I prefer to apply information hiding, thus excluding the details of implementation to the greatest possible extent. Courses like "Operating Systems Implementation" fail to do this. > there has been a debate on for a very long time about whether a > university should "educate" or "train", which is buzzwordery for "Should > a university equip people to reason, understand, and learn new things, > or should a university teach people to become useful code jocks > instantly on exiting school?" Both; the former can be done within the context of the latter. > I do think you're wildly wrong. In any case, the program you describe > is like the Associate's Degree course I took years and years ago; taught > me to be a pretty good COBOL programmer, taught me to write OS/360 JCL. > Other than a couple of years of $14--$20 K jobs (this was some time ago, > not bad money then) it was damned little use. No, it isn't. Software engineering is a long way from COBOL & JCL, which today remain of little use. (Flames to /dev/null...) > Ten years from now, I'll bet a fancy dinner that you'll be glad you > did get what theory you got, A sure bet, since I have repeatedly stated that theory was useful... > and sorry you didn't get an OS course when you could have. Too bad you attached the "theory" part... how about betting a bottle of superb Eiswein just on the OS material? Bill Wolfe, wtwolfe@hubcap.clemson.edu
crm@romeo.cs.duke.edu (Charlie Martin) (12/05/89)
In article <7296@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: > Again, not exactly. I prefer to apply information hiding, thus > excluding the details of implementation to the greatest possible > extent. Courses like "Operating Systems Implementation" fail to > do this. > And, now, given that the course you were objecting to is called "operating systems implementation" I *might* agree with you; depends on the content of the course. A course on operating systems implementations which turns out to be the internals of, say, VMS, doesn't seem like a proper "core" course. On the other hand, the course title doesn't tell all that much. (I once took a course on programming methodology which turned out to be taught more or less as a course on time-efficient implementation of algorithms for OR problems.) (I do love it when these discussions on the net begin to converge. It always makes me feel like I've learned something....) > > Both; the former [teach to think] can be done within the context of > the latter. [train to be effective code jock 'on delivery'] > >> I do think you're wildly wrong. In any case, the program you describe >> is like the Associate's Degree course I took years and years ago; taught >> me to be a pretty good COBOL programmer, taught me to write OS/360 JCL. >> Other than a couple of years of $14--$20 K jobs (this was some time ago, >> not bad money then) it was damned little use. > > No, it isn't. Software engineering is a long way from COBOL & JCL, > which today remain of little use. (Flames to /dev/null...) > "The program you describe is *like* the...." meaning similar in effect or intent. They didn't teach software engineering per se in this course I was talking about becuase the course was about the same time as the NATO Summer School; it wasn't a term yet, really, much less a field of study. My point is that a sequence which leads to IS programming in Ada under UNIX is likely to be just as useless in 20 years as the one I took that taught RPG II and COBOL under 360 DOS and OS. At least I hope so. A sequence that teaches file system organization, concurrency and multiple access, architectures and the tradeoffs among architectural choices, and some kind of formal understanding of program and programming language semantics is much more likely to be giving you tools that you'll use in 20 years. Whether this stuff ought to be taught as it often is, in courses on operating systems, data bases, etc, is another question. You've about got me convinced that it should not be. (pace Tony Wassermann, but maybe organizing "software engineering" sorts of computer science kowledge around those courses is not as good an idea as it first seems....) One point that you seem to have in mind, that a student can be an effective team member immediately upon graduation, seems idealistic at best. No other engineering discipline does so; back at GTE I was told that it took about one year to become effective as an engineer, no matter where you were from or what your background was. There is that much domain knowledge and "corporate culture" to be learned. Charlie Martin (crm@cs.duke.edu,mcnc!duke!crm)
murphyn@cell.mot.COM (Neal P. Murphy) (12/05/89)
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) writes: >From crm@romeo.cs.duke.edu (Charlie Martin): >... >> university should "educate" or "train", which is buzzwordery for "Should >> a university equip people to reason, understand, and learn new things, >> or should a university teach people to become useful code jocks >> instantly on exiting school?" > Both; the former can be done within the context of the latter. >... Wrong! Either Mr. Wolfe is an extremely arrogant and argumentive SOB, or he has absolutely no idea of what education is. There is an exceptionally vast difference between `training' and `education'. Animals can be trained to perform specific tasks. Of course, humans can be trained to perform specific tasks. That is training. Education involves training. It also involves much, much more. It involves learning history - what events have lead us to where we are today; it involves learning the geography of our planet - where those events took place; it involves learning political and social science - why we have society and government, and how they evolved; education involves learning literature - how the art of communication has developed from primitive grunts and tones and diagrams to today's verbal, musical and pictorial media; education involves the study of philosophy - why we are here, if, in fact, we are anywhere at all, or even if there is anywhere to be in the first place! Education involves much more than training. The purpose of college or university is not to train students to perform a specific task. Its purpose is to enable students to learn as much as they can about as many different topics as they can, so that by the time they graduate and enter the industrial/business world, they will know how *and* where to find answers to questions, solutions to problems, without having to pass the problem on to someone else. A technician, who has been trained, passes an unknown problem to an appropriate engineer, who has been educated, who solves it and instructs the technician how to fix it. A college/university education enables one to communicate effectively with anyone: co-workers, management, fellow countrymen, foreigners in his land, or natives in their own land. An education teaches him that the needs of other people aren't necessarily the same as his needs, that these differences are part of what make up the dynamics of this planet. An education enables one to realize that people like Mr. Wolfe do come along, people who are incapable of learning anything new because they already know everything, that their way is the one true way. How many times have we heard *that* in the past? Mr. Wolfe, why did you bother going to college and wasting all that money, when you were born omniscient? You obviously didn't get anything out of your time there, at least nothing you couldn't have learned by reading a couple books. The purpose of college is to give the student as broad a background as possible, so that that student will be able to lead as productive, good and independent a life as possible. A college/university has only four years to perform its task, so there are compromises. And, since nothing is perfect, there will be those who slip through with a narrow base, or little to no base at all. And yes, in addition to the standard classical education, a college/university trains its engineering students to be wizards who can mix potions, mix signals, mix dirt, or mix bits and create new and wonderful things from these mixtures. NPN uunet!motcid!murphyn
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (12/06/89)
From crm@romeo.cs.duke.edu (Charlie Martin): > My point is that a sequence which leads to IS programming in Ada under > UNIX is likely to be just as useless in 20 years as the one I took that > taught RPG II and COBOL under 360 DOS and OS. At least I hope so. A > sequence that teaches file system organization, concurrency and multiple > access, architectures and the tradeoffs among architectural choices, and > some kind of formal understanding of program and programming language > semantics is much more likely to be giving you tools that you'll use in > 20 years. The idea is to combine practical software engineering technology (Ada, CASE environments, and so on) with an understanding of how to apply it (software engineering, algorithm design and analysis, IS domain knowledge), an analytical understanding of computation (particularly NP-completeness and its implications, and the use of approximation algorithms as a pragmatic response), business skills (how to give presentations, how to interview, etc.) and a means of professional development and continuing education (membership in ACM). It is obviously unacceptable to produce workers whose skills will inevitably become outdated without connecting them into a mechanism such as ACM whereby they will obtain continuing education; sadly, this is precisely what has been ignored by CS programs for years. > One point that you seem to have in mind, that a student can be an > effective team member immediately upon graduation, seems idealistic at > best. No other engineering discipline does so; back at GTE I was told > that it took about one year to become effective as an engineer, no > matter where you were from or what your background was. There is that > much domain knowledge and "corporate culture" to be learned. Having been a GTE-er myself, I am familiar with this perspective. However, I think it is largely due to the fact that coop programs are still running in low gear as far as universities are concerned. Bill Wolfe, wtwolfe@hubcap.clemson.edu
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (12/06/89)
From me:
> The idea is to combine practical software engineering technology...
Forgot one: the ability to search and utilize the computing literature
effectively in the process of solving practical problems.
This is another biggie that IMHO, CS curricula give short shrift to,
at least at the undergraduate level...
Bill Wolfe, wtwolfe@hubcap.clemson.eduge@kunivv1.sci.kun.nl (Ge' Weijers) (12/06/89)
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) writes: > Performance should be documented by the OS vendor. Compilers should > document their performance with respect to the OSs they run under. If > this is not done, then the information can be developed by specialists > in performance issues. There is no need for application developers to > do the work of the vendors or or the performance issues analysts. > I repeat: Enough to understand how to use the tool, and no more. Perhaps ALL computing professionals should go on a really good documentations course in their first year. Your point would become true. At the moment I use this operating system which is not even understood by its authors :-( Ge' Weijers Ge' Weijers Internet/UUCP: ge@cs.kun.nl Faculty of Mathematics and Computer Science, (uunet.uu.net!cs.kun.nl!ge) University of Nijmegen, Toernooiveld 1 6525 ED Nijmegen, the Netherlands tel. +3180612483 (UTC-2)
nick@lfcs.ed.ac.uk (Nick Rothwell) (12/06/89)
In article <489@cherry5.UUCP>, murphyn@cell (Neal P. Murphy) writes: >There is an exceptionally >vast difference between `training' and `education'. Animals can be trained >to perform specific tasks. Of course, humans can be trained to perform >specific tasks. That is training. Education involves training. It also >involves much, much more. > ... more ... I think it can be put more succinctly in the context of CS. If a University were to "train" people, we'd have loads of graduates who knew about C and Unix but who were unable to look towards the future. A lot of companies are interested in "training" because they want C/Unix hackers or other people for the "present". They don't look to the future at all (new languages, concurrency, new systems, etc.), until we show them what it might look like, when they start to get interested. Universities should be educating people to have a broader knowledge and encompass (even, shock horror, *develop*) the ideas of the future, not work with the technology we're stuck with today. Nick. -- Nick Rothwell, Laboratory for Foundations of Computer Science, Edinburgh. nick@lfcs.ed.ac.uk <Atlantic Ocean>!mcvax!ukc!lfcs!nick ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ "You're gonna jump!?" "No, Al. I'm gonna FLY!"
mitchell@community-chest.uucp (George Mitchell) (12/06/89)
In article <489@cherry5.UUCP> murphyn@cell.mot.COM (Neal P. Murphy) wrote:
`Education involves much more than training. The purpose of college or
`university is not to train students to perform a specific task. Its
`purpose is to enable students to learn as much as they can about as many
`different topics as they can, so that by the time they graduate and enter
`the industrial/business world, they will know how *and* where to find
`answers to questions, solutions to problems, without having to pass the
`problem on to someone else. A technician, who has been trained, passes an
`unknown problem to an appropriate engineer, who has been educated, who
`solves it and instructs the technician how to fix it.
`
`A college/university education enables one to communicate effectively with
`anyone: co-workers, management, fellow countrymen, foreigners in his land,
`or natives in their own land. An education teaches him that the needs of
`other people aren't necessarily the same as his needs, that these
`differences are part of what make up the dynamics of this planet.
` .... The purpose of college is to give
`the student as broad a background as possible, so that that student will be
`able to lead as productive, good and independent a life as possible.
What has happened to our concept of public schooling? I thought that
grades K through 12 were supposed to prepare us to be citizens of our
state, country, and the world. This is the arena in which we are
supposed to have our exposure to "as many different topics" as possible.
If the public schools are not succeeding, the remedy should NOT be to
accept the situation and help the fortunate in college.
In the college/university we are expected to specialize. Most students
have major/minor fields of study and learn as much as they can about
those fields. However, within this narrower scope, the tendency IS
towards education (providing knowledge) rather than training (providing
practice in performance). It is for these reasons that many schools
have developed extensive cooperative programs to supplement knowledge
with experience and professions have provided apprenticeships (MD
interns).
I suggest that the followup to this thread move to sci.edu. The
discussion has moved from what background is necessary to prepare the
computer science/software engineering student for life after college to
what is the purpose of education after high school. In a country with
extensive adult education programs, colleges no longer need to consider
themselves the last chance an individual has to become enlightened.
Given the rapidly decreasing employment opportunities for inexperienced
people without highly specialized knowledge, perhaps the role of the
college and the curricula it offers needs revamping.
--
/s/ George vmail: 703/883-6029
email: mitchell@community-chest.mitre.org [alt: gmitchel@mitre.arpa]
snail: GB Mitchell, MITRE, MS Z676, 7525 Colshire Dr, McLean, VA 22102manis@cs.ubc.ca (Vincent Manis) (12/07/89)
In article <7335@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: > Forgot one: the ability to search and utilize the computing literature > effectively in the process of solving practical problems. Taken to the extreme, this goal would result in courses such as `Generating and Maintaining MVS Systems': there are still a lot of jobs, and still a lot of problems, in the IBM mainframe environment. :-) :-) More seriously, the goal of a university CS program is not to produce trained people for industry, and more than the goal of a university physics program is to produce cyclotron jockeys. What I hope is that the graduates from our program are (at an entry level, to be sure) scientists, not technologists. That goal in no way means that a computer scientist cannot apply his/her knowledge and skills on practical problems. However, I would also like as many of our graduates as possible to be interested and qualified in advancing the science itself, in other words, in pursuing further study in the field. My attitude comes from the elitist notion that the role of a university should be one of developing future leaders of society. I am less interested in turning out students who know the complete bug list for 4.3BSD IPC than I am in turning out students who really understand CS, and choose to apply it in innovative ways, to contribute to the field, or to teach it to others. Teaching the principles of operating systems or compiler design is not done because the student will use it, but rather because it teaches the student some principles which are deemed to be important. (If the student doesn't see that by the end of the course, then either the student or the instructor--or both--are at fault!) -- Vincent Manis <manis@cs.ubc.ca> "There is no law that vulgarity and Department of Computer Science literary excellence cannot coexist." University of British Columbia -- A. Trevor Hodge Vancouver, BC, Canada V6T 1W5 (604) 228-2394
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (12/08/89)
From manis@cs.ubc.ca (Vincent Manis): > I would also like as many of our graduates as > possible to be interested and qualified in advancing the science itself, > in other words, in pursuing further study in the field. There should be a separate track for those who are interested in doing this. The needs of a PhD candidate are considerably different from the needs of a future practitioner. Bill Wolfe, wtwolfe@hubcap.clemson.edu
crm@romeo.cs.duke.edu (Charlie Martin) (12/09/89)
In article <5899@ubc-cs.UUCP> manis@grads.cs.ubc.ca (Vincent Manis) writes: >In article <7335@hubcap.clemson.edu> >billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: > >> Forgot one: the ability to search and utilize the computing literature >> effectively in the process of solving practical problems. > >Taken to the extreme, this goal would result in courses such as >`Generating and Maintaining MVS Systems': there are still a lot of jobs, >and still a lot of problems, in the IBM mainframe environment. :-) :-) > No. nonono, nein, nicht wahr, non, iee. What it ought to do is result in courses like "Operating Systems Concepts" that explain the ideas, and teach people the language or the field, so they can find and read those manuals. It also ought to result in courses that emphsize the existance of the literature, and require people to read it, to search through it, and to be able to use it effectively. Given the skills Bill talks about, he and I would almost agree: given that people know how to read the literature effectively, they can find out anything else they need to know. I would argue that they need a broader background than Bill imagines. Unfortunately, a lot of that (it seems to me) is stuff that people ought to come to college with. I'm not claiming I did; I don't know how many people do. But it doesn't mean that they have to take courses in each operating system or set of particular products they may have to someday deal with. Charlie Martin (crm@cs.duke.edu,mcnc!duke!crm)
murphyn@cell.mot.COM (Neal P. Murphy) (12/09/89)
mitchell@community-chest.uucp (George Mitchell) writes: >In article <489@cherry5.UUCP> murphyn@cell.mot.COM (Neal P. Murphy) wrote: -inclusion deleted- >What has happened to our concept of public schooling? I thought that >grades K through 12 were supposed to prepare us to be citizens of our >state, country, and the world. This is the arena in which we are >supposed to have our exposure to "as many different topics" as possible. >If the public schools are not succeeding, the remedy should NOT be to >accept the situation and help the fortunate in college. It almost got by you, but it got snagged in your sweater. The *concept* of public schooling is fine. It is the practice that has suffered. >In the college/university we are expected to specialize. Most students >have major/minor fields of study and learn as much as they can about >those fields. However, within this narrower scope, the tendency IS >towards education (providing knowledge) rather than training (providing >practice in performance). It is for these reasons that many schools >have developed extensive cooperative programs to supplement knowledge >with experience and professions have provided apprenticeships (MD >interns). However, within the narrower scope you mentioned, there is still *plenty* of room to generalize. I specialized in computing science, not civil engineering. But within CS, I generalized. I learned about compilers, numerical methods, opsys's, human factors, etc. I also learned about philosophy, Literature, welding, casting, tooling (grundge lab), and other divers topics. I'm not saying that everyone should be so divers. I am saying that there should be a minimal amount. This is backed up by the sheer numbers of engineers, scientists, politicians, public officials, managers and others who are *incapable* of presenting their ideas and notions in any media (spoken, written, etc.) so that their audiences can readily understand them. They can not spell; they can not put together a clear sentence. The roots of this problem are found in the primary and secondary education. The discussion of the roots *does* belong in sci.edu, or elsewhere. But the discussion of the education of our children in the field of computing sciences belongs here, in this group (comp.edu). Curricula for the teaching of CS to grammar and high school students need to be developed. A large amount of the material that is taught in post-secondary schools *should* be taught in grades K-12. Why, you ask? Because. Because computers are an integral part of our world today. Because there are fewer and fewer jobs available that do *not* involve the use of computers. Because *so much* of one's time in college is spent learning the fundamentals and basics of CS, one doesn't have the time to learn such advanced concepts as software *engineering* and human factors (there's no reason for any computer produced today to be even remotely "user hostile" :-).) As an example of this back-shifting of education, the advanced algebra I took as a freshman in high school was the same algebra my Dad took as a sophomore or junior in college. >I suggest that the followup to this thread move to sci.edu. The >discussion has moved from what background is necessary to prepare the >computer science/software engineering student for life after college to >what is the purpose of education after high school. In a country with There were two arguments, initially, in this thread: teach operating systems as a subject and as a place to use most of what one has learned in CS, and don't require OS at all, because it is worthless. There was also an argument that software engineering needs to be included there somewhere. I'm saying that there isn't enough time available in four years to teach all that is necessary to produce a young person who is capable of producing advanced software while learning, on his own, new and better techniques. Back-shift the teaching of appropriate topics. This will empty up to 3 semesters of college, in which students will be able to learn what they need: an appreciation of the finer arts, and appreciation for detail, the facts to do a job well, and the knowledge they need so that they will be able to stand up and say, "I designed, developed, implemented and documented this software. I am proud of the result. I believe that there are no dangerous errors in the code. If any are found, I alone accept responsibility for those errors." How many CS-types do you think would even understand what that statement means, never mind be willing to make it? There aren't many, in my opinion. NPN
mitchell@community-chest.uucp (George Mitchell) (12/12/89)
In article <535@cherry5.UUCP> murphyn@cell.mot.COM (Neal P. Murphy) wrote:
` .... The *concept* of public schooling is fine.
`It is the practice that has suffered....
`
`I am saying that there should be a minimal amount [of generalization].
`This is backed up by the sheer numbers of engineers ... who are *incapable*
`of presenting their ideas and notions in any media (spoken, written, etc.) so
`that their audiences can readily understand them. They can not spell; they
`can not put together a clear sentence.... A large amount of the material
`that is taught in post-secondary schools *should* be taught in grades K-12.
`
`.... I'm saying that there isn't enough time available in four
`years to teach all that is necessary to produce a young person who is
`capable of producing advanced software while learning, on his own, new
`and better techniques. Back-shift the teaching of appropriate topics.
`This will empty up to 3 semesters of college, in which students will
`be able to learn what they need...
I interpret the above (and the omitted verbiage) to be a vote in favor
of general education in public school and professional education in
college. The length of time necessary to complete a minimal
professional education will vary. BUT, the time one spends after
secondary school should not be mandatorily filled with the 3Rs or other
basic education. These should be a requirement for entry.
This takes no position on the desireability of preparation for research.
I will note that BSN (Nursing - another undergraduate professional
curriculum) programs include an introduction to nursing research.
--
/s/ George vmail: 703/883-6029
email: mitchell@community-chest.mitre.org [alt: gmitchel@mitre.arpa]
snail: GB Mitchell, MITRE, MS Z676, 7525 Colshire Dr, McLean, VA 22102snidely@nosun.UUCP (David Schneider) (12/16/89)
In article <16391@duke.cs.duke.edu> crm@romeo.UUCP (Charlie Martin) writes: > >Given the skills Bill talks about, he and I would almost agree: given >that people know how to read the literature effectively, they can find >out anything else they need to know.... > >Unfortunately, a lot of that (it seems to me) is stuff that people ought >to come to college with. I'm not claiming I did; I don't know how many >people do.... >Charlie Martin (crm@cs.duke.edu,mcnc!duke!crm) > Ummm, when I got out of high school, I thought I was pretty good at using the library. But like most skills, this one improves with practice. Someone asked (in this context), "is public education failing, that we have to teach basic skills in college?" Yes and no. Remember that public schooling through secondary grades (high school) has to deal with a wide variety of students. Some pick up skills quickly, and some very slowly. Most students consider themselves incarcerated, and aren't willing to make it easy for teachers to teach. Our colleges aren't elitist enough to have just the quick learners that show great willingness (I doubt any college ever has -- those that try still get the rich kids who attend for the prestige). Even with the cream of the crop, few have had enough practice at basic skills that more practice is unnecessary (I confess, I had to look up how many 'c's are in necessary). The very breadth of topics covered in primary and secondary grades makes it hard to get enough practice. So remember, colleges can't avoid going over the same stuff again, because students don't get it all right the first time around. Or the second, or.... from the soapbox of Dave Schneider Friday, Dec 15