kcby@scotty.Atlanta.NCR.COM (K. C. Yakemovic) (11/08/89)
In article <3152@hydra.gatech.EDU> russ@prism.gatech.EDU (Russell Shackelford) writes: > >[stuff deleted about how CS education misses the boat] > >[stuff deleted about how CS education is probably going to get better >slowly] > >one of the problems is that we don;t really know what it is we're trying >to accomplish. we understand little about people and problems and >problem solving and etc., etc., etc. now, many folks disagree, claiming >that The Answer really lies in mathematical models or cognitive psych or >(fill in your religion here). > >what do you think CS education should try to DO? I think that maybe the 'common ground' between what industry needs and what computers science research needs may lie in the area of teaching students how to a) take a problem and figure out the (relevent) unknowns b) how to find the answers to those questions c) how to communicate what they are thinking (to other people or to machines). As a simple example of a, consider the word problems given in "math" tests. Life presents us with a lot of word problems. So learning to represent the relevent aspects of a problem in a 'mathematical' or other structured way is key to problem solving. Whether the problem is "design a software system which solves the problems of this class of customer" or "design a test of some piece of CS theory", the ability to do this type of analysis is critical. As far as how to find answers to questions, there are many sources for answers. Two general classifcations might be "stored" knowledge sources (such as books) and "living" knowledge sources (such as other people). We need to know how to get answers out of *both* types of sources. Learning how to apply answers given in other fields (languages/jargon) is also a useful skill for both researchers and industry. Cross domain fertilization is possible... but not if people haven't been exposed to the idea that getting ideas from other places is "good". And finally, what to me is perhaps the biggest "gotcha"... all the good ideas in the world, and even the solutions to problems, aren't worth anything if people can't communicate what they know to others. The reluctance of CS graduates to write things down is legendary. I've been told that communication skills should be taught "before" the undergraduate CS training begins. However, IMHO if a person can't express themselves in understandable English, the chances of their sucessfully explaining to a machine what they want *it* to do are slim. An exmpale of what could be done by the CS program here would be getting students to write so that people not directly involved with their area of study can understand it. (As a side benefit, this might help the poor industry programmer who hasn't learned the latest university jargon to make use of the ideas!) Since my CS degree is a 'few' years old, there wasn't much in the way of "basics" being taught at the time. Having learned, with the help of my teachers, how to learn, I was able to learn the "basics" on my own. I've found this ability to teach myself (by figuring out what I didn't know and then looking for the answers) and the ability to express my self in written (and spoken) communication have been extremely useful tools in industry... as well when I've done any post-graduate coursework. It might be useful to note that I wouldn't expect these things to be taught in standalone courses but rather as principals within all CS cousework. - KC Burgess Yakemovic kcby@Atlanta.ncr.com
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)
karam@sce.carleton.ca (Gerald Karam) (11/09/89)
In article <1989Nov7.205549.19821@psuvax1.cs.psu.edu> ian@theory.cs.psu.edu (Ian Parberry) writes: >... I see a lot of undergraduate students who resent being >taught Problem Solving. I had a student in my office last month who said >that he was going to work for IBM, and that he didn't need anything that we >had taught him. He claimed that Problem Solving is too academic. Apparently >all he thinks he needs is skill in the syntax of a programming language or >two. A startlingly large number of undergraduates here at Penn State think >that theoretical Computer Science is B***S***. > >You can lead a student to knowledge, but you can't make him think. a colleague of mine had a clever response to a first year (freshperson) engineering student who complained that understanding why things were done (in a first "problem solving with computers" course) was getting in the way of the nuts and bolts (syntax of pascal etc.). since it was at the beginning of term, the prof. said, "If you hurry, you can probably get your money back and go and register at (name of local diploma school deleted) instead!" I believe the student got the point. gerald karam asst. professor karam@sce.carleton.ca karam@sce.uucp
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
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 | | +----------------------------------+------------------+
rang@cs.wisc.edu (Anton Rang) (11/10/89)
In article <1049@scotty.Atlanta.NCR.COM> kcby@scotty.Atlanta.NCR.COM (K. C. Yakemovic) writes: >I think that maybe the 'common ground' between what industry needs and what >computers science research needs may lie in the area of teaching students >how to > > a) take a problem and figure out the (relevent) unknowns > b) how to find the answers to those questions > c) how to communicate what they are thinking > (to other people or to machines). Two great things I was lucky enough to have at my undergrad school: 1. A software engineering course (5 years ago, even). Every quarter, the teacher talked to groups on campus to find some semi-real world problem (though small enough to be feasible for the class to do in a quarter). She gathered some of the initial information, gave it to us as a group, and basically told us to write a program which would solve their problem--the class as a whole, not individuals or small teams. We had to learn to work in groups, how to communicate between groups of programmers (and with the users, when we had questions), etc. Our program nearly worked at the end of the quarter (though it still had bugs, mostly misunderstandings between teams). The important things which the course taught, I think, were: (a) Problems don't come with complete specifications; you have to get clarifications from people who are not always very computer-literate. (b) Working in large teams (30 people in the class; we broke up into 6 subgroups of 5 people each) is difficult. Communication is very important; misunderstandings are a nightmare when putting the final version of the program together. (c) Clear specifications for what modules do and how they interact are very important. I found this course to be one of the best I've ever had, though it was definitely frustrating at times. (For the curious, the project during the quarter I took the class was writing a program to keep track of investments made by members of an investing club on campus, not unlike keeping track of shares in a mutual fund.) Unfortunately, the next year the teacher retired, and the class started becoming watered-down (there had been complaints about how much work it was). 2. An independent-study program where area companies provided some real-life programs to the math & CS departments. Students could work on these for independent study credit. This was sort of like an internship, without having to miss school (though without pay). Anton P.S. Any others ever run into software engineering courses where the whole class writes something? I've mentioned this to a few people, and they usually say it can't be done! Worked in my case, anyway.... +----------------------------------+------------------+ | 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
lfd@cbnewsm.ATT.COM (leland.f.derbenwick) (11/11/89)
In article <1593@ultb.UUCP>, jrj1047@ultb.UUCP (J.R. Jarrett) 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 > >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 The portions based on physical laws tend to be specific to each discipline. EEs don't care whether you push on a rope or not! :-) > [ ... ] > operating systems :-}. But, in math, I learned how to attack problems, > systematically solve them and show how they were solved. With that kind > [ ... ] Problem-solving, including presentation of the solutions so that any reasonably competent fellow engineer can understand them, is part of the "basic set of disciplines to engineering." Problem-solving tends to be taught primarily in the first couple undergraduate years, in the common courses that all engineering majors must take. These may be officially Civil Engineering or other "traditional" majors: I had a couple (in the early 70's) in a virtual department titled simply "Engineering", taught by professors from the regular departments. If taught badly, such courses are an almost total waste, but if taught well, which includes distinguishing the general principles from the specific problems being used to illustrate them, they are invaluable. I was lucky: I had excellent professors for all 4 semesters of "common" engineering courses. My understanding is that most schools now use only one or two common engineering courses, some not even that. The justification is to avoid the "waste" of an EE major's time learning some Civil Engineering, etc. But that might make it very hard to teach the intro courses well, leading to them being even more of a perceived waste... Anyone currently (or recently) in school care to comment? -- Lee Derbenwick, AT&T Bell Laboratories, Warren, NJ -- lfd@cbnewsm.ATT.COM or <wherever>!att!cbnewsm!lfd
gillies@p.cs.uiuc.edu (11/11/89)
I'd like to hear someone expound on the exact differences between a
computer scientist and an engineer.
What sorts of disciplines do M.E.'s and Civil Engineers learn that
computer scientists miss? What kinds of "methods of thought" do we
need to stress more in computer science?
Don Gillies, Dept. of Computer Science, University of Illinois
1304 W. Springfield, Urbana, Ill 61801
ARPA: gillies@cs.uiuc.edu UUCP: {uunet,harvard}!uiucdcs!gilliesbillwolf%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 _______________________________________________________________________________
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 <1593@ultb.UUCP>, by jrj1047@ultb.UUCP (J.R. Jarrett): > 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. This is where most people in computing get into trouble. The basic disciplines of engineering have NOTHING to do with laws of physics, properties of materials, properties of shapes, etc. The basic disciplines of engineering deal with how you define, attack, and resolve a problem by constructing one (or more) artifacts. Since programs are far and away the most complex artifacts that man constructs, the engineering disciplines are every bit as necessary as they are in simpler tasks. >>> 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 am aware of the difference! > 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! :-))) But only a small exaggeration. If you concentrate on number bashing (numerical analysis), which I studiously avoided, you probably end up with a skill set similar to that of a CS major. > 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. The thing is that the courses that you really learn how to use your head are pretty rough for many people. That had a lot to do with how most CS departments got started in the 60s. 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
-----------------------------------------------------------------------------rsd@sei.cmu.edu (Richard S D'Ippolito) (11/17/89)
In article <876@awdprime.UUCP> Ron Woan writes: >...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. At the engineering design level, all of this is just implementation detail. I expect the implementation language and compiler designers to have taken care of all of that. >...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. Same thing -- this is valuable stuff and is a necessary part of computer science (though very specialized, like courses in large rotating machine design in the EE department), but it is not really teaching software engineering. 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
sullivan@aqdata.uucp (Michael T. Sullivan) (11/18/89)
From article <1989Nov17.164340.20977@world.std.com>, by madd@world.std.com (jim frost): > > While each <CS and SE> 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). Aren't there Chemistry and Chemical Engineering degrees? You can even go to schools and pick whether to get a BA or BS in Computer Science. Obviously CS and SE degrees would overlap. Heck, CS and EE degrees overlap to an extent. But CS and SE programs can deviate enough to warrant separate degrees. -- Michael Sullivan uunet!jarthur.uucp!aqdata!sullivan aQdata, Inc. San Dimas, CA
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
mjl@cs.rit.edu (11/19/89)
In article <7093@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: >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? > > The cooperative education movement is gaining strength here in the > US, but obviously Canada, at least at Waterloo, is far ahead in that > area. > > Bill Wolfe, wtwolfe@hubcap.clemson.edu With all due respect (and I do respect the folks at Waterloo a lot!), cooperative education was begun by the University of Cincinnati in the early part of this century (1912 I believe). It's been an integral part of the RIT educational experience since 1914. When our undergraduate computer science program was started in 1972, one year of cooperative education was made a graduation requirement, and it remains so to this day. Of course, those of us in the co-op biz know that industrial support is essential ingredient to our success (gentle hint). 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
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)
Just an observation: a surgeon is an engineer (applying known techniques) most of the time. a surgeon developing new operating techniques is in my opinion doing scientific work. Computer science/engineering is not the only field that does not have two types of education, one for engineering, and one for science. Designers of HUGE bridges usually are scientists too, as the engineering aspects of large bridges are not that well understood by all engineers in the trade. 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)
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)
sullivan@aqdata.uucp (Michael T. Sullivan) (12/02/89)
From article <549@kunivv1.sci.kun.nl>, by ge@kunivv1.sci.kun.nl (Ge' Weijers): > > a surgeon is an engineer (applying known techniques) most of the time. > a surgeon developing new operating techniques is in my opinion doing > scientific work. > ... > Computer science/engineering is not the only field that does not have > two types of education, one for engineering, and one for science. But is a surgeon the same as a medical researcher the same as your family doctor? Their educations must overlap but they also must branch out at some point. How else do you explain all those different doctor initials at the end of their names. -- Michael Sullivan uunet!jarthur.uucp!aqdata!sullivan aQdata, Inc. aqdata!sullivan@jarthur.claremont.edu San Dimas, CA
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)
sullivan@aqdata.uucp (Michael T. Sullivan) writes: >But is a surgeon the same as a medical researcher the same as your >family doctor? Their educations must overlap but they also must branch >out at some point. How else do you explain all those different doctor >initials at the end of their names. They must be from an English-speaking country, where they fall for that sort of thing :-) It's true, but their education diverges at a late date, after graduation. 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)
ge@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
rsd@sei.cmu.edu (Richard S D'Ippolito) (12/08/89)
In article <1325@castle.ed.ac.uk> nick@lfcs.ed.ac.uk (Nick Rothwell) writes: >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. I ain't gonna touch this one at all, no, I ain't! 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 -----------------------------------------------------------------------------
ge@kunivv1.sci.kun.nl (Ge' Weijers) (12/08/89)
nick@lfcs.ed.ac.uk (Nick Rothwell) writes: >In article <489@cherry5.UUCP>, murphyn@cell (Neal P. Murphy) writes: >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. I'm afraid this happens anyway. At least in the Netherlands universities 'educate' (i.e. train) more and more people unable to invent new things. Ingenuity is not a requirement these days. It is not needed to complete secondary education, a good memory and reasonable intelligence is all that is needed. This has been true since the dark ages. (Teaching Latin has not changed for 1500 years. So much for progress.) > 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. What do you do with those admitted to your university, unable of creative thought? Either you let them flunk, which lets your funding dry up, or you let them graduate. I don't like it, but that's life. Only prestigious or downright rich universities can be very selective. Bah. 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)
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
mjl@cs.rit.edu (12/11/89)
In article <16391@duke.cs.duke.edu> crm@romeo.UUCP (Charlie Martin) writes: > >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. Try this one on for size. At RIT, we have four required junior level courses: Operating Systems, Programming Language Concepts, Data Communications, and Introduction to Computer Science Theory. (This isn't as constricting as it may sound because we are on a quarter system.) The goal of each of these courses is to present concepts that we believe are of general, long lasting significance. In the case of the language concepts course, a subgoal is to make students view design & implementation from perspectives that are radically different from the imperative style they've used to that point. With the exception of the languages course, *none* of these require programming. Even in PLC the assignments are kept small, so students can concentrate on the conceptual models rather than issues of size and complexity. The OS course uses operating systems as a convenient vehicle for the discussion of resource management, concurrency, security, etc. "Convenient" here means that our students are fairly sophisticated users by the time they take the course, so it is easy to find familiar examples to motivate the topics we're interested in. We rarely do full case studies in class (though students typically write a paper that achieves the same result). We do employ examples from common systems like Unix, MS/DOS, and VMS to show contrasting approaches and engineering tradeoffs. Of course we have follow on courses in each area so that students interested in the area can explore it in greater depth. Generally these follow on courses require design and implementation (as in Operating Systems Lab, Language Processors, and Distributed Systems Lab). We also have a Software Engineering track for those interested in the problems of large scale systems of any type. The core courses give breadth, whereas the senior level specialty courses give modest depth. We believe that this approach, combined with mandatory co-op, gives our students solid preparation for either graduate school or for the start of a career in software development. Comments? (as if I have to ask :-) Mike Lutz Rochester Institute of Technology mjl@cs.rit.edu ...!rutgers!rochester!rit!mjl Mike Lutz Rochester Institute of Technology, Rochester NY UUCP: {rutgers,cornell}!rochester!rit!mjl INTERNET: mjlics@ultb.isc.rit.edu
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
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (12/17/89)
From snidely@nosun.UUCP (David Schneider): > Most students consider themselves incarcerated, and aren't > willing to make it easy for teachers to teach. And leading to low efficiency in the educational system; by making education truly free, in the sense that one can pursue education according to one's own interests (limited only by the need to satisfy an absolutely minimal set of prerequisites), we would see a tremendous increase in the efficiency and effectiveness of education. But surely (heavy sarcasm) this could not compare with the thrill of force-feeding irrelevant material to a captive audience which really doesn't give a damn, right??? After all, what could possibly lead us to believe that students treated this way will conclude that education is completely worthless and decide to seek the more obvious material benefits of selling crack instead?? How could we reasonably believe that by totally disregarding their interests and forcing them to study wars of the 17th century, we could be seeing to it that they seek out drugs as an escape mechanism??? No, our educational system is doing a FINE job of producing pregnant teenage dropouts who give birth to heroin-addicted babies -- why should we change a thing??? Bill Wolfe, wtwolfe@hubcap.clemson.edu
bralick@psuvax1.cs.psu.edu (Will Bralick) (12/18/89)
In article <7474@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: | From snidely@nosun.UUCP (David Schneider): | > Most students consider themselves incarcerated, and aren't | > willing to make it easy for teachers to teach. | | And leading to low efficiency in the educational system; by making ~~~~~~~~~~ I guess we just aren't cranking out those degrees fast enough. We want more degrees for lower effort. | education truly free, in the sense that one can pursue education | according to one's own interests But everyone is sure to pursue their own interests, anyway. There is more to being an educated person than pursuing one's own interests no matter how fascinating such interests might be. I urge you to read M. Adler's Paiedia (sp?) Proposal. He argues that the schools are not just a training ground for future employment, but also the institution wherein the society's future adult citizens are taught. How is an ignorant person supposed to have cultivated interests in "irrelevant" subjects without being exposed to those subjects? | (limited only by the need to satisfy | an absolutely minimal set of prerequisites), Ah, yes, we don't want any of those foolish _breadth_ requirements, now do we? But, wait, there's more! Why bother with those silly prerequisites? Heck, people should be able to take anything they want. How can you justify having some teacher decide what previous work is to be required before taking a class? You will probably want the job of ensuring that only _really_ necessary courses are prescribed; we don't want those poor oppressed students to actually learn anything that isn't absolutely necessary for their exact job that they will get upon graduation. | But surely (heavy sarcasm) this could not compare with the thrill | of force-feeding irrelevant material to a captive audience which | really doesn't give a damn, right??? Students (based on their limited life experiences) cannot see the relevance of the material. What a surprise! The surprise is that we should put the "inmates in charge of the asylum" and have the admittedly ignorant students decide what the relevant material _is_. I am almost willing to agree that they at least shouldn't be "captive" audiences. That would be no problem if they would not have to be supported by the people who had the responsibility and self-discipline as young adults to learn the "irrelevant" material. | After all, what could possibly | lead us to believe that students treated this way will conclude that | education is completely worthless and decide to seek the more obvious | material benefits of selling crack instead?? After all, we all know that the only reason for pursuing an education is to make more money. In which case the student cannot _possibly_ learn anything that will make him more money than selling crack, so the student shouldn't bother going to school, anyway. | How could we reasonably | believe that by totally disregarding their interests and forcing them | to study wars of the 17th century, we could be seeing to it that they | seek out drugs as an escape mechanism??? If a student "seeks out drugs as an escape mechanism" because they are forced to (gasp!) actually read (that's right -- read) an actual book that they wouldn't actually _buy_ because it doesn't fit within the narrow confines of their "interests" then such a person should seek professional help. | No, our educational system | is doing a FINE job of producing pregnant teenage dropouts who give | birth to heroin-addicted babies -- why should we change a thing??? Our educational system has its problems, but I think that the culture students _live in_ bears far more blame for the above than the school where they spend only 30 hours/week. Regards, -- Will Bralick | ... when princes think more of bralick@psuvax1.cs.psu.edu | luxury than of arms, they lose bralick@gondor.cs.psu.edu | their state. with disclaimer; use disclaimer; | - Niccolo Machiavelli
elm@sprite.berkeley.edu (ethan miller) (12/18/89)
In article <1989Dec18.042005.19231@psuvax1.cs.psu.edu> bralick@psuvax1.cs.psu.edu (Will Bralick) writes: %In article <7474@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: %| From snidely@nosun.UUCP (David Schneider): %| > Most students consider themselves incarcerated, and aren't %| > willing to make it easy for teachers to teach. %| %| And leading to low efficiency in the educational system; by making % ~~~~~~~~~~ %I guess we just aren't cranking out those degrees fast enough. We %want more degrees for lower effort. No, what billwolf is saying is that education is inefficient; it takes longer to teach anything than it should take. In several of my undergrad classes, I don't feel that I got a semester's worth of material during the semester. *That* is inefficiency. %| (limited only by the need to satisfy %| an absolutely minimal set of prerequisites), % %Ah, yes, we don't want any of those foolish _breadth_ requirements, %now do we? But, wait, there's more! Why bother with those silly %prerequisites? Heck, people should be able to take anything %they want. How can you justify having some teacher decide %what previous work is to be required before taking a class? %You will probably want the job of ensuring that only _really_ %necessary courses are prescribed; we don't want those poor %oppressed students to actually learn anything that isn't absolutely %necessary for their exact job that they will get upon graduation. Anyone who can do well in a class should be allowed to take it. I'm glad that Brown was lenient on prerequisites; it meant that I got to take some classes I might not have otherwise. If I can handle the material, and I have the necessary background (or I'm willing to get it on my own), why shouldn't I be allowed to take an advanced class. Besides, many "advanced" classes in the liberal arts, such as history, merely delve deeply into one subject; a broad view of history (covering hundreds of years) may not be necessary for studying the Russian revolution. The Mayan civilization (and the Greeks for that matter) have little to do with it, yet History 1 is often considered a prerequisite for all other history classes. %| But surely (heavy sarcasm) this could not compare with the thrill %| of force-feeding irrelevant material to a captive audience which %| really doesn't give a damn, right??? % %Students (based on their limited life experiences) cannot see the %relevance of the material. What a surprise! The surprise is that we %should put the "inmates in charge of the asylum" and have the admittedly %ignorant students decide what the relevant material _is_. By putting the students in charge of their curriculum, you give them the choices, so they're interested in what they learn. You won't learn if you're force-fed. If you really are concerned with providing help on the curriculum, advise the students; don't order them around. The faculty only has more experience, not more intelligence. %| How could we reasonably %| believe that by totally disregarding their interests and forcing them %| to study wars of the 17th century, we could be seeing to it that they %| seek out drugs as an escape mechanism??? % %If a student "seeks out drugs as an escape mechanism" because they %are forced to (gasp!) actually read (that's right -- read) an actual %book that they wouldn't actually _buy_ because it doesn't fit within %the narrow confines of their "interests" then such a person should %seek professional help. But why should I be forced to read a book on something that doesn't interest me? Instead of forcing me to read the book, why not get me interested? %| No, our educational system %| is doing a FINE job of producing pregnant teenage dropouts who give %| birth to heroin-addicted babies -- why should we change a thing??? % %Our educational system has its problems, but I think that the culture %students _live in_ bears far more blame for the above than the school %where they spend only 30 hours/week. They're the same thing. Why is it that teachers get paid so little and have so little respect? Imagine the looks when a scientist earning $60K decides to teach high school and earn $25K. Why must such a person be "under too much pressure?" Why isn't teaching held in higher regard? It seems that the older generation is to blame; the schools often get the dregs of a discipline, not its stars. "Those who can, do; those who can't teach" seems to determine who teachs in schools, so is it any wonder that a student is fortunate to get one or two good teachers per year? The schools are to blame, but it is society that runs the schools. ethan ================================= ethan miller--cs grad student elm@sprite.berkeley.edu #include <std/disclaimer.h> {...}!ucbvax!sprite!elm Witty signature line condemned due to major quake damage.
rsc@altair.uucp (Steve Cunningham) (12/18/89)
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) writes (16 Dec 89 18:32:41 GMT) But surely (heavy sarcasm) this could not compare with the thrill of force-feeding irrelevant material to a captive audience which really doesn't give a damn, right??? After all, what could possibly lead us to believe that students treated this way will conclude that education is completely worthless and decide to seek the more obvious material benefits of selling crack instead?? How could we reasonably believe that by totally disregarding their interests and forcing them to study wars of the 17th century, we could be seeing to it that they seek out drugs as an escape mechanism??? No, our educational system is doing a FINE job of producing pregnant teenage dropouts who give birth to heroin-addicted babies -- why should we change a thing??? Bill Wolfe, wtwolfe@hubcap.clemson.edu I've been reading Mr. Wolfe's requests for BA's from trade schools for some time, and this time pushes me over the limit. *flame on* Let's just all add him to our kill files and end this; there are some real questions in CS education that deserve our attention instead. *flame off*
bralick@psuvax1.cs.psu.edu (Will Bralick) (12/19/89)
In article <33278@ucbvax.BERKELEY.EDU> elm@sprite.berkeley.edu (ethan miller) writes: | In article <1989Dec18.042005.19231@psuvax1.cs.psu.edu> bralick@psuvax1.cs.psu.edu (Will Bralick) writes: | % In article <7474@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: | % | | % | And leading to low efficiency in the educational system; by making | % ~~~~~~~~~~ | % I guess we just aren't cranking out those degrees fast enough. We | % want more degrees for lower effort. | | No, what billwolf is saying is that education is inefficient; it takes | longer to teach anything than it should take. In several of my | undergrad classes, I don't feel that I got a semester's worth of material | during the semester. *That* is inefficiency. What he is saying is that you have interests that you wish to pursue, and that taking courses that you perceive to be inconsequential is a waste of your time. You seem to be saying that in at least some (one?) of your courses you didn't get a "semester's worth of material" implying that you had time to pursue your interests, I suppose. | Anyone who can do well in a class should be allowed to take it. And how can one hope to predict that the student has the necessary background to be successful in a course? By self-affirmation, I suppose. Now, if a student thinks a course might look good on a resume' and the student takes the course without adequate preparation, then the student should fail (or drop) to course, right? Perhaps the student will struggle along visiting the professor and/or asking questions in class that were covered in the prerequisite courses. | % | But surely (heavy sarcasm) this could not compare with the thrill | % | of force-feeding irrelevant material to a captive audience which | % | really doesn't give a damn, right??? | % | % Students (based on their limited life experiences) cannot see the | % relevance of the material. What a surprise! The surprise is that we | % should put the "inmates in charge of the asylum" and have the admittedly | % ignorant students decide what the relevant material _is_. | | By putting the students in charge of their curriculum, you give them | the choices, so they're interested in what they learn. The students don't learn because they don't choose to become interested in the subject matter. They are -- spoiled. They only want to do what they want to do. At least education can disabuse them of the notion that they will be able to live like that :-). | You won't | learn if you're force-fed. If one is sufficiently mature one needn't be "force-fed." Students who are wise enough to design their own curriculum are certainly wise enough to carefully select a school which will satisfy their objectives while keeping their "irrelevant" courses to a minimum. Students who make an informed decision about the school they will attend and then whine about having to take "irrelevant" courses need to grow up. | % | How could we reasonably | % | believe that by totally disregarding their interests and forcing them | % | to study wars of the 17th century, we could be seeing to it that they | % | seek out drugs as an escape mechanism??? | % | % If a student "seeks out drugs as an escape mechanism" because they | % are forced to (gasp!) actually read (that's right -- read) an actual | % book that they wouldn't actually _buy_ because it doesn't fit within | % the narrow confines of their "interests" then such a person should | % seek professional help. | | But why should I be forced to read a book on something that doesn't | interest me? Instead of forcing me to read the book, why not | get me interested? One might get oneself interested. One might be in a situation where one is faced with doing something that one regards as distasteful, but which will be beneficial in the long term. Instead of hunkering down and attempting to make the best of it, some people prefer to complain about how unfair life is. | % | No, our educational system | % | is doing a FINE job of producing pregnant teenage dropouts who give | % | birth to heroin-addicted babies -- why should we change a thing??? | % | % Our educational system has its problems, but I think that the culture | % students _live in_ bears far more blame for the above than the school | % where they spend only 30 hours/week. | | They're the same thing. I disagree. One's educational system is not the sum total of one's culture. | Why is it that teachers get paid so little and I recommend this be pursued in sci.econ. | have so little respect? Some teachers deserve little respect. Most certainly deserve our respect and the respect of their students, but then again, we have been talking about students who are spoiled; who only respect their own desires. | Imagine the looks when a scientist earning | $60K decides to teach high school and earn $25K. Why should they care what anybody _else_ thinks? Some people are motivated by other things than money. Some people enjoy teaching. Regards, -- Will Bralick | ... when princes think more of bralick@psuvax1.cs.psu.edu | luxury than of arms, they lose bralick@gondor.cs.psu.edu | their state. with disclaimer; use disclaimer; | - Niccolo Machiavelli
murphyn@cell.mot.COM (Neal P. Murphy) (12/20/89)
In article <7474@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: >From snidely@nosun.UUCP (David Schneider): >> Most students consider themselves incarcerated, and aren't >> willing to make it easy for teachers to teach. > >... > > But surely (heavy sarcasm) this could not compare with the thrill > of force-feeding irrelevant material to a captive audience which > really doesn't give a damn, right??? After all, what could possibly >... I don't know how many of you, out there, are parents. I myself am not one. But, it seems that most of the problems in education stem from the changing of society in general. Look at the East Germans going back to E. Germany after a few weeks of working in the West: they didn't like having to work so hard for what they were earning. Now, look at us, here in the US (and perhaps elsewhere). We work exceedingly hard so that we can assure ourselves a future where we won't have to work so hard. Our choice. But, there are too many parents out there who are working long and hard hours. They simply are not there to teach their children the discipline they will need later in life. The children have no direction. They turn to drugs because that's the only thing that forces them into a course of action. For years, parents attempted to shift the teaching of discipline (I do *not* mean corporal punishment, here.) to the schools. The teachers weren't (and aren't) prepared for that. And the school boards, courts, children's advocacy groups, etc. won't let them in any case. We have an entire generation of children growing up with *NO* discipline whatever. They don't know the concept of doing something simply because they must. They only do something if they *WANT* to do it. Unfortunately for them, most of education involves force-feeding *seemingly* irrelevant material to students. By this, I mean, "Take my word, student. You need to learn this, even if *you* don't see its relevancy, because *I* see its relevancy, and that relevancy may not become apparent to you for weeks, months, or even years from now. So learn it, as best you can." Our teachers have very little support from the parents. Education begins at home. It is supplemented at school. >... > is doing a FINE job of producing pregnant teenage dropouts who give > birth to heroin-addicted babies -- why should we change a thing??? Our educational system is producing pregnant (and impregnating, to be fair) teenage dropouts addicted to drugs because society, as a whole, has failed them. We have failed them. And we are stuck with supporting them for the rest of their lives. At this point, we have two choices: we can hope and pray that the problem goes away on its own (not likely), or we can work together to fix the system, to ensure that such widescale abuse of our children does not again occur (also not likely to happen). Somebody - anybody - please prove me wrong. NPN
byoder@smcnet.UUCP (Brian Yoder) (12/20/89)
In article <1989Dec18.042005.19231@psuvax1.cs.psu.edu>, bralick@psuvax1.cs.psu.edu (Will Bralick) writes: > In article <7474@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: > | From snidely@nosun.UUCP (David Schneider): > | > Most students consider themselves incarcerated, and aren't > | > willing to make it easy for teachers to teach. > | > | And leading to low efficiency in the educational system; by making > ~~~~~~~~~~ > I guess we just aren't cranking out those degrees fast enough. We > want more degrees for lower effort. Should I take your criticism as advocacy of _inefficient_ education? In the original context David was talking about students who are taught the same material ten times even though they understood it the first time. The most frustrating example of this in my experience was in the study of english. As I remember, I felt like a captive being force-fed the same material every year from 4th grade to college (where I was fortunate enough to test out of further rehashing of the same material). Just think of how much additional material I could have covered in that time! What a waste. > | education truly free, in the sense that one can pursue education > | according to one's own interests > > But everyone is sure to pursue their own interests, anyway. They can't if they are in a straightjacket curriculum and can't choose an alternate school. Don't get me wrong on the issue of loose vs. tight curricular requirements. I think that if anything, today's curricula are too lenient in that they don't REALLY require students to learn anything. (If you don't believe that, I have a few million illiterates with diplomas I'd like to introduce you to :-) The problem is that the limits to fast advancement are a brick wall ("You CAN'T learn algebra in 5th grade, it'll melt your brain.") while slower students are not REQUIRED to learn the material that they are taught. The result of this is that a student can't get an adequate education at school and he can't change schools (unless his parents are pretty rich and there's a GOOD school nearby. I believe that there are very few students really getting a good education these days. Do you call that pursuing interests? [Stuff Deleted for brevity] > How is an ignorant person supposed to have cultivated interests > in "irrelevant" subjects without being exposed to those subjects? Considering that the current system doesn't even teach students to read and write reliably, I can hardly conclude that it is very effective in training students to have cultivated tastes. > | (limited only by the need to satisfy > | an absolutely minimal set of prerequisites), > > Ah, yes, we don't want any of those foolish _breadth_ requirements, > now do we? How does repeating material that has already been learned contribute to the ability, attention span, and classroom time available for other non-basic coursework? Perhaps the reason that after 13 years of education a large percentage of college freshmen can't compute with fractions or write a complete sentence is that they were never required to do so? Could that be? Until teachers get the guts to REQUIRE students to learn material before passing them along, having a broad curriculum will do as much good as pouring EXPENSIVE wine into a glass with a hole in the bottom. > But, wait, there's more! Why bother with those silly > prerequisites? Heck, people should be able to take anything > they want. How can you justify having some teacher decide > what previous work is to be required before taking a class? The way things work these days, students are not assumed to know anything much before the class anyway (if that was the expectation, why is there so much repeated material?). I would suggest that some kind of "advanced placement" tests would serve as perfect prerequisites for higher level classes (with only scores of 90% allowing entry). Just think, maybe we could require students who had taken the prerequisite classes to take those tests too. If they didn't make the grade, what would this indicate to you? > You will probably want the job of ensuring that only _really_ > necessary courses are prescribed; we don't want those poor > oppressed students to actually learn anything that isn't absolutely > necessary for their exact job that they will get upon graduation. I don't recall getting the impression that the initial posting implied the sort of situation I have often seen wherein curricular requirements were relaxed and students became lazy and took lots of mickey-mouse classes. Presently, we don't teach students much about the basics, job-oriented areas, or cultural areas. Just ask the typical high school senior who Napoleon was, what three fifths of 15 is, or what job he wants to get when he graduates (there's a chance of his actually answering that one). > | But surely (heavy sarcasm) this could not compare with the thrill > | of force-feeding irrelevant material to a captive audience which > | really doesn't give a damn, right??? > > Students (based on their limited life experiences) cannot see the > relevance of the material. That is a comment I heard all through my education and it's as much garbage as it was then. When a student says that he knows a set of material (in some cases students have a better understanding of the material that their teachers) he ought to be provided with an opportunity to prove it and be allowed to move on to more challenging work. In practice, on those rare occasions when students can escape from the boredom of repeated material, there's nowhere for him to go (heaven forbid he should be allowed into the higher-level class, then we'll have the same problem again next year...better put the little trouble-maker on ice until the other kids can catch up! :-). Students DO know when they are bored. Telling a bored student that he's not bored seems to be pretty presumptious even for a professional educator. > What a surprise! The surprise is that we > should put the "inmates in charge of the asylum" and have the admittedly > ignorant students decide what the relevant material _is_. Who admitted that students are ignorant about what they know? Should they not be given an opportunity to show whether or not they are ready to progress and meet appropriate objectives and move on? How can we deny the opportunity for slower students to also demonstrate their level of understanding so as to not be pushed along into work they are not ready for? Isn't this lack of objective evaluation criteria why we have so many students who are either pushed hrough each grade without learning anything or restricted from reaching their full potential? > I am almost > willing to agree that they at least shouldn't be "captive" audiences. That's an odd reaction...if they are not learning, then it's the student's problem...if they don't like what we are dishing up, let 'em hit the road. It's about time that the educational establishment take some responsibility for allowing students to fail by not failing them. Schools that pass students on to higher grades/graduation without application of standards are to blame when those students are unable to function. I don't like the idea of abandoning students like that (unless they are criminals of course). My impression was that most of the educationists out there resisted the idea of "writing off" poor students. I hope that opinion isn't representative of the conventional wisdom of the educational establishment these days. > That would be no problem if they would not have to be supported by > the people who had the responsibility and self-discipline as young > adults to learn the "irrelevant" material. > > | After all, what could possibly > | lead us to believe that students treated this way will conclude that > | education is completely worthless and decide to seek the more obvious > | material benefits of selling crack instead?? > > After all, we all know that the only reason for pursuing an education > is to make more money. In which case the student cannot _possibly_ > learn anything that will make him more money than selling crack, so > the student shouldn't bother going to school, anyway. 1. As I read it, the original posting was talking about learning ANY material, not just job-oriented material. 2. There's nothing wrong with wanting to learn a subject in depth (job- related or not) except that it might require some adequate teacher preparation. My gut reaction is that this is the REAL reason for resistance to studying subjects in depth. 3. Students who are bored out of their minds can have their attention pulled away by anything, not just drugs or (Gasp!) material benefits or (Horrors!) plans for a future career. I'm not talking about adding classes in Rap music and creative skate-boarding. I'm talking about trying to teach students REAL information. Since when are students required to read a REAL book? (ie. not a text book) I can't remember ever being required to read an interesting book in all of my educational years. Fortunately, I happened to love reading (I still do) and found lots of interesting material on my own. > | How could we reasonably > | believe that by totally disregarding their interests and forcing them > | to study wars of the 17th century, we could be seeing to it that they > | seek out drugs as an escape mechanism??? > > If a student "seeks out drugs as an escape mechanism" because they > are forced to (gasp!) actually read (that's right -- read) an actual > book that they wouldn't actually _buy_ because it doesn't fit within > the narrow confines of their "interests" then such a person should > seek professional help. > | No, our educational system > | is doing a FINE job of producing pregnant teenage dropouts who give > | birth to heroin-addicted babies -- why should we change a thing??? > > Our educational system has its problems, but I think that the culture > students _live in_ bears far more blame for the above than the school > where they spend only 30 hours/week. I don't believe that for a minute. That might be an adequate excuse (though certainly not much of a comfort to the people whose lives are miserable because the the 13 years of 30 hours/week they didn't learn to read. At least they have a (worthless) diploma. I grew up in a nice rural area...very little crime, most families were not broken, no big "cultural problems", yet 50% of the graduates were barely literate and only a few could have been considered "educated". I don't think my experiences are isolated instances or a limited problem. Most of the people with whom I discuss this relate similar tales. Will the "educators" ever acknowledge their role in this dirty little secret? I doubt it. That's why changes need to come from the outside. Does anyone honestly expect for the NEA to allow evaluation of the effectiveness of it's members? Not on your life. > Regards, > Will Bralick Brian Yoder -- -<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>- | Brian Yoder | answers *byoder(); | | uunet!ucla-cs!smcnet!byoder | He takes no arguments and returns the answers | -<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-
dalamb@qucis.queensu.CA (David Lamb) (12/20/89)
In article <7474@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: > And leading to low efficiency in the educational system; by making > education truly free, in the sense that one can pursue education > according to one's own interests (limited only by the need to satisfy > an absolutely minimal set of prerequisites), we would see a tremendous > increase in the efficiency and effectiveness of education. Uh, who gets to decide what's "minimum"? I bet a lot of people who set up the programs you complain about thought their prerequisites *were* minimal - even, perhaps, less than minimal (that is, inadequate). > > But surely (heavy sarcasm) this could not compare with the thrill > of force-feeding irrelevant material to a captive audience which > really doesn't give a damn, right??? I have never met a teacher who got thrills from force-feeding "irrelevant" material. I have met many who disagreed with their students about what was relevant. Sometimes the students may have been right, but sometimes "irrelevant" may be a codeword for "poorly taught" or "too hard" or, perhaps, "won't help me get my first job". Students who take responsibility for their own educations usually do a lot better than those who don't. We ought to think about getting rid of things in existing programs that make it hard for a student to do this, and it's worth examining curricula from this perspective. However, I suspect that large class sizes and the modern tendency to pile on a heavy assignment load during the term is a bigger part of the problem than curriculum requirements. Even the well-motivated students have too little flexibility and time to pursue education on their own. David Alex Lamb ARPA Internet: David.Lamb@cs.cmu.edu Department of Computing dalamb@qucis.queensu.ca and Information Science uucp: ...!utzoo!utcsri!qucis!dalamb Queen's University phone: (613) 545-6067 Kingston, Ontario, Canada K7L 3N6
reggie@dinsdale.nm.paradyne.com (George W. Leach) (12/20/89)
In article <583@cherry5.UUCP> murphyn@cell.mot.COM (Neal P. Murphy) writes: >I don't know how many of you, out there, are parents. I myself am not one. I am. I've got three kids, one in second grade and two pre-schoolers. >But, it seems that most of the problems in education stem from the changing >of society in general. Look at the East Germans going back to E. Germany >after a few weeks of working in the West: they didn't like having to work >so hard for what they were earning. Now, look at us, here in the US (and >perhaps elsewhere). We work exceedingly hard so that we can assure ourselves >a future where we won't have to work so hard. Our choice. But, there are >too many parents out there who are working long and hard hours. They simply >are not there to teach their children the discipline they will need later >in life. Yes, unfortunately I do see a great deal of problems due to the working couple with children. My wife was able to retire from the workforce to Stay home with the kids. Not every family can afford to do this. Others simply put career ahead of children. The former have no choice. The later do. In my mind, it is better to not have children at all, if one of the parents can not put there career on hold until the children are older. >The children have no direction. Young children need a great deal of direction. If you are not there to give it to them, then who will? The seeds are sown early in life for much of what will happen with them in the future. >They turn to drugs because that's the only thing that forces them into a >course of action. Forces who? The parents? Many parents try to ignore drug problems, if they even know about them. My own parents were much too nieve to even be able to recognize a drug problem. I'm sure many parents are in the same boat. Also, I think you are oversimplifying the reasons that kids turn to drugs. There are many reasons and even kids who have loving, caring parents that try to motivate them to do well in school and provide them with a positive outlook on life may find they have a drug problem to deal with. Remember kids do have a mind of their own. Some will have to learn by experience rather than from the experiences of others. >For years, parents >attempted to shift the teaching of discipline (I do *not* mean corporal >punishment, here.) to the schools. The teachers weren't (and aren't) prepared >for that. I saw plenty of that going to Catholic school as a kid. Lots of parents Would send their kids there to get "discipline". You can also see parents shipping their kids off to a military school for this. >And the school boards, courts, children's advocacy groups, etc. >won't let them in any case. We have an entire generation of children growing >up with *NO* discipline whatever. They don't know the concept of doing >something simply because they must. They only do something if they *WANT* >to do it. I don't know if this happens because parents expect the schools to provide discipline for their kids or if they simply don't know how to do so themselvers. Someone once told me "just because you can make babies doesn't make you a parent". There is a whole lotta truth in that statement. Unfortunately, no one trains you to be a good parent. All you know is what you experienced as a child. Your perspectives change as you become a parent. I don't know how many times I have told my father how much more I appreciate how he raised me now that I am presented with raising kids of my own. It is a tough job. Unfortunately, many are not equiped to cope with it, nor are they able to (and in many cases willing) to get help. Did you ever ask someone why they are having children? I bet a great many people do so because "it is expected of them" or "it is what everyone does, you get a job, get married, buy a house, and have kids". I'll bet that far too many people don't have kids because they want to commit to the job of spending the next eighteen to twenty-one years raising them. This fact has nothing to do with socio-economic conditions either. You find rich and poor people who haven't got a clue as to why they have kids. >Unfortunately for them, most of education involves force-feeding *seemingly* >irrelevant material to students. By this, I mean, "Take my word, student. You >need to learn this, even if *you* don't see its relevancy, because *I* see >its relevancy, and that relevancy may not become apparent to you for weeks, >months, or even years from now. So learn it, as best you can." Our teachers >have very little support from the parents. Education begins at home. It is >supplemented at school. Exactly. However, I *do* feel that kids would be much better motivated to do well in school *if* they could be shown how what they are learning applies to life. For example, while we still lived in New York, my son attended the Fieldston School. In the upper grades for history they would study a certain time period. For example, the Pilgrims. They would not just read about them, but they would actually experience their lifestyle. The kids would try to make clothing the same way they did, cook food, build things, etc.... What an eye opener that was. And the kids are really into it. But it takes money, time, and a caring teacher. If a child has the support at home they can excel no matter what the situation of school. Without that support, no school can correct the problem. >Our educational system is producing pregnant (and impregnating, to be fair) >teenage dropouts addicted to drugs because society, as a whole, has failed >them. We have failed them. And we are stuck with supporting them for the >rest of their lives. At this point, we have two choices: we can hope and >pray that the problem goes away on its own (not likely), or we can work >together to fix the system, to ensure that such widescale abuse of our >children does not again occur (also not likely to happen). Somebody - >anybody - please prove me wrong. 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
bralick@cs.psu.edu (Will Bralick) (12/21/89)
In article <462@smcnet.UUCP> byoder@smcnet.UUCP (Brian Yoder) writes: >In article <1989Dec18.042005.19231@psuvax1.cs.psu.edu>, bralick@psuvax1.cs.psu.edu (Will Bralick) writes: >> In article <7474@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: > >> | education truly free, in the sense that one can pursue education >> | according to one's own interests >> >> But everyone is sure to pursue their own interests, anyway. > >They can't if they are in a straightjacket curriculum and can't choose >an alternate school. Don't get me wrong on the issue of loose vs. tight >curricular requirements. I think that if anything, today's curricula >are too lenient in that they don't REALLY require students to learn anything. When I went to school (K-12), I was not spending my every waking moment on schoolwork. I daresay today's students aren't either. In the students' free time they will pursue their own interests -- that seems axiomatic to me. The complaint that I have seen in this group is that the poor oppressed student is not allowed to pursue his own interests _all the time_. Presumably, that means that if the student's interest is watching tee-vee then he should be allowed to do that 24-hours/day. We basically agree that the educational system needs reform. The problem is that there are some that advocate turning the schools into trade schools wherein one learns job skills and no bovine excrement like history, literature, etc. I disagree. > ... >> | But surely (heavy sarcasm) this could not compare with the thrill >> | of force-feeding irrelevant material to a captive audience which >> | really doesn't give a damn, right??? >> >> Students (based on their limited life experiences) cannot see the >> relevance of the material. > >That is a comment I heard all through my education and it's as much >garbage as it was then. I was referring to new, but "irrelevant" information, like history, etc. >they are bored. Telling a bored student that he's not bored seems to >be pretty presumptious even for a professional educator. I am not saying students aren't bored. Rather I am saying that students are bored because they don't make the effort to become interested in the material (once again, I am referring to _new_ ("irrelevant") material). Teachers cannot _force_ students to become interested. The best they can do is to communicate an enthusiasm for learning in general and their subject in particular. The student must choose to become interested and then make the effort to learn the material. > ... > > Since when are students required to read a REAL book? (ie. not a text book) I read Tale of Two Cities, The Rime of the Ancient Mariner, Romeo and Juliett, Fahrenhiet 451, etc. in 9th grade English class. These qualify as real books, I think. Other courses (e.g. science, math, etc.) were, of course, taught from textbooks. >> Our educational system has its problems, but I think that the culture >> students _live in_ bears far more blame for the above than the school >> where they spend only 30 hours/week. > >I don't believe that for a minute. That might be an adequate excuse (though >certainly not much of a comfort to the people whose lives are miserable >because the the 13 years of 30 hours/week they didn't learn to read. At >least they have a (worthless) diploma. Huh? I am saying that schools in 30 hours/week cannot overcome the influence of the environment the student lives in. If the environment is anti-intellectual and/or anti-education, then the student will likely have a negative attitude towards school. The student's peers are particularly important here. >That's why changes need to come from the outside. Does >anyone honestly expect for the NEA to allow evaluation of the effectiveness >of it's members? Not on your life. I agree, now about the direction of change ... Regards, -- Will Bralick | ... when princes think more of bralick@psuvax1.cs.psu.edu | luxury than of arms, they lose bralick@gondor.cs.psu.edu | their state. with disclaimer; use disclaimer; | - Niccolo Machiavelli
byoder@smcnet.UUCP (Brian Yoder) (12/22/89)
In article <1989Dec21.051715.1574@cs.psu.edu>, bralick@cs.psu.edu (Will Bralick) writes: > In article <462@smcnet.UUCP> byoder@smcnet.UUCP (Brian Yoder) writes: > >In article <1989Dec18.042005.19231@psuvax1.cs.psu.edu>, bralick@psuvax1.cs.psu.edu (Will Bralick) writes: > >> In article <7474@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: > > > >> | education truly free, in the sense that one can pursue education > >> | according to one's own interests > >> > >> But everyone is sure to pursue their own interests, anyway. > > > >They can't if they are in a straightjacket curriculum and can't choose > >an alternate school. Don't get me wrong on the issue of loose vs. tight > >curricular requirements. I think that if anything, today's curricula > >are too lenient in that they don't REALLY require students to learn anything. > > When I went to school (K-12), I was not spending my every waking moment > on schoolwork. I daresay today's students aren't either. In the > students' free time they will pursue their own interests -- that seems > axiomatic to me. What I was talking about was pursuing the interests associated with getting an education. I am also not talking about giving the students a choice of whether they would like to do less work than normal. What about the student who really wants to learn and does so quickly? He still has to waste time reviewing information that has already been digested. I also seem to remember spending three weeks in high school learning about what the relationships between price, demand, and availability of goods. I can't think of any way to spend more than about five minutes explaining it. The teacher just kept repeating the same material almost like some kind of mantra. That's a waste of time and prevented me from pursuing my interests (ie. learning about economics). I suppose the fact that the teacher didn't have any background in econ. didn't really help much either, she just finished reading the textbook herself. > The problem is that there are some that advocate turning the schools into > trade schools wherein one learns job skills and no bovine excrement like > history, literature, etc. I disagree. As do I. I guess it is a matter of priorities in part. Since schools don't do a very good job of teaching reading/writing and don't provide very good vocational training, it is not unreasonable to give these issues a higher priority. Than humanities. I suppose that the fact that humanities are almost universally poorly taught (IMHO) makes people want to see students spend less time on them. Personally, I was disgusted with history, literature, and philosophy during my school years. What I learned in class was that those are boring musty stupid subjects. After I graduated and had the time to explore the subjects on my own, I found that there are wonderful and exciting things to be learned in these areas. The interesting parts had been blotted out by textbook writers and boring teachers. We need to do a better job of teaching all of these, but if I had to concentrate, I'd make ABSOLUTELY sure that the basics and the sciences were taught properly. You can live without Plato, you can't live (well) without reading and math. > > Since when are students required to read a REAL book? (ie. not a text book) > > I read Tale of Two Cities, The Rime of the Ancient Mariner, Romeo and > Juliett, Fahrenhiet 451, etc. in 9th grade English class. These qualify > as real books, I think. Other courses (e.g. science, math, etc.) were, > of course, taught from textbooks. That's not too bad, it's more than most other schools I have heard about. Then again, it's not too good when you consider that you are talking about 4 books in 16 (?) years. Were all of those done in your 9th grade year? If so that sounds like you got one good class out of the whole experience (isn't it interesting that you still remember that class? What about your 8th grade english class? Could this be a key?). > >I don't believe that for a minute. That might be an adequate excuse (though > >certainly not much of a comfort to the people whose lives are miserable > >because the the 13 years of 30 hours/week they didn't learn to read. At > >least they have a (worthless) diploma. > > Huh? I am saying that schools in 30 hours/week cannot overcome the > influence of the environment the student lives in. If the environment > is anti-intellectual and/or anti-education, then the student will > likely have a negative attitude towards school. The student's peers > are particularly important here. Granted that makes it tough to teach these kids, but how can anyone justify passing them from grade to grade without any learning taking place? If they don't learn the alphabet by they time they are 15 they should still be in first grade. What does a diploma represent if it doesn't indicate that the student learned anything, but rather "put his time in". Clear objective standards for evaluation of performance should be enforced all along the way. Has anyone here read anything written by a guy named "Keller" who advocated testing be used to regulate movement between classes rather than time? I read a few things by and about him many years ago and it really seemed to make sense at the time. > >That's why changes need to come from the outside. Does > >anyone honestly expect for the NEA to allow evaluation of the effectiveness > >of it's members? Not on your life. > > I agree, now about the direction of change ... That sounds like it deserves a new thread....After Christmas! Merry Christmas, Brian -- -<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>- | Brian Yoder | answers *byoder(); | | uunet!ucla-cs!smcnet!byoder | He takes no arguments and returns the answers | -<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-
bralick@cs.psu.edu (Will Bralick) (12/29/89)
In article <471@smcnet.UUCP> byoder@smcnet.UUCP (Brian Yoder) writes: | In article <1989Dec21.051715.1574@cs.psu.edu>, bralick@cs.psu.edu (Will Bralick) writes: | > | > When I went to school (K-12), I was not spending my every waking moment | > on schoolwork. I daresay today's students aren't either. In the | > students' free time they will pursue their own interests -- that seems | > axiomatic to me. | | What I was talking about was pursuing the interests associated with getting | an education. So was I. The pursuit of one's educational interests can certainly be conducted (augmented) outside of class. I think that it is clear that if a person is interested in something then they will work on it on their own time, whereas something with which one is unfamiliar or uninterested will not be pursued without some external motivation. Students will pursue their _perceived_ interests without external motivation. | ... | I also seem to remember | spending three weeks in high school learning about what the relationships | between price, demand, and availability of goods. I can't think of any | way to spend more than about five minutes explaining it. The teacher | just kept repeating the same material almost like some kind of mantra. | That's a waste of time and prevented me from pursuing my interests (ie. | learning about economics). So the teacher spent 50 minutes per day, five days per week, for three weeks regurgitating material from the textbook. I suspect that this is an oversimplification, but we can let that pass. Even so, you have wasted 750 minutes (12.5 hours). I doubt that that was the _only_ time you wasted during that three weeks. I would be surprised to learn that you watched _no_ television, played _no_ video/pinball games, etc. I don't excuse the teacher from her poor performance, but I doubt whether most teenagers if _given_ 750 minutes would find anything more productive to do with the time. | > The problem is that there are some that advocate turning the schools into | > trade schools wherein one learns job skills and no bovine excrement like | > history, literature, etc. I disagree. | | As do I. I guess it is a matter of priorities in part. Since schools don't | do a very good job of teaching reading/writing and don't provide very good | vocational training, it is not unreasonable to give these issues a | higher priority. Than humanities. I was with you up to the "vocational training" part. The one area where our secondary schools seem to have some success is in turning out is auto mechanics, carpenters, secretaries, etc. IMHO it should be the _last_ priority of the secondary school to train a student for a trade. The first priority should be to teach the basic skills (reading, writing, mathematics, computer skills, library skills, thinking skills, a foreign language, etc.) necessary for the student to pursue a lifetime of learning (i.e. the pursuit of their own interests), the second should be to produce a literate, informed electorate, and once those two missions are accomplished, the student can then be trained in life skills (how to balance a check book, why one shouldn't borrow for consumption, how to prepare meals, change diapers, etc.), and then finally one (or several) trades. | ... | if I had to concentrate, I'd make ABSOLUTELY sure that the basics | and the sciences were taught properly. We agree. Basics first. Ideally these are taught _before_ secondary school. Parents, the primary and middle schools have all failed to provide students who are prepared for secondary education. This is a more serious problem than whether little Johnny is bored with Dickens. | > > Since when are students required to read a REAL book? (ie. not a text book) | > | > I read Tale of Two Cities, The Rime of the Ancient Mariner, Romeo and | > Juliett, Fahrenhiet 451, etc. in 9th grade English class. These qualify | > as real books, I think. Other courses (e.g. science, math, etc.) were, | > of course, taught from textbooks. | | That's not too bad, it's more than most other schools I have heard about. | Then again, it's not too good when you consider that you are talking | about 4 books in 16 (?) years. Were all of those done in your 9th | grade year? If so that sounds like you got one good class out of the | whole experience (isn't it interesting that you still remember that | class? What about your 8th grade english class? Could this be a key?). Actually, I picked on 9th grade because I remembered the class and the teacher. I had other good reading experiences in my other years, too. I participated in a reading group in the 7th and 8th grades on Saturday mornings at my elementary school, etc. By the time I reached 10th grade, I was pretty well read. However, I find that I have a long way to go to catch up to where I _should_ be, since I have only been reading technical stuff (except for a few (required!) breadth courses in undergraduate studies) during the last decade or so. | > Huh? I am saying that schools in 30 hours/week cannot overcome the | > influence of the environment the student lives in. If the environment | > is anti-intellectual and/or anti-education, then the student will | > likely have a negative attitude towards school. The student's peers | > are particularly important here. | | Granted that makes it tough to teach these kids, but how can anyone | justify passing them from grade to grade without any learning taking place? I certainly don't. I think we agree far more than we disagree. The educational establishment has been more concerned with the students' psycho-social development than their educational development for several years. Trying to keep children with their "peer" group instead of flunking them (when they deserve it). | > >That's why changes need to come from the outside. Does | > >anyone honestly expect for the NEA to allow evaluation of the effectiveness | > >of it's members? Not on your life. | > | > I agree, now about the direction of change ... | | That sounds like it deserves a new thread....After Christmas! I have suggested that Adler's Padeia Proposal provides a suitable model. Comments? Regards, -- Will Bralick | ... when princes think more of bralick@psuvax1.cs.psu.edu | luxury than of arms, they lose bralick@gondor.cs.psu.edu | their state. with disclaimer; use disclaimer; | - Niccolo Machiavelli