Path: utzoo!utgpu!water!watmath!clyde!att-cb!att-ih!alberta!cdshaw From: cdshaw@alberta.UUCP (Chris Shaw) Newsgroups: comp.software-eng Subject: Re: Soft eng in 1st yr classes.. pontification Message-ID: <1167@pembina.UUCP> Date: 28 Mar 88 05:51:20 GMT References: <555@psu-cs.UUCP> <1434@ur-tut.UUCP> <3415@bunker.UUCP> <5359@utah-cs.UUCP> <36845UH2@PSUVM> <563@psu-cs.UUCP> Reply-To: cdshaw@pembina.UUCP (Chris Shaw) Organization: U. of Alberta, Edmonton, Alberta, Canada Lines: 129 In article <563@psu-cs.UUCP> warren@psu-cs.UUCP (Warren Harrison) writes: >This is a very good suggestion. However, here is my problem ... how do you >justify to a student that a program to compute the sum of a list of numbers >uses a procedure? One suggestion below. >One approach that I have found >to work quite well however is in the COBOL programming course. The first few >programs involve the (extensive) modification of a working program of several >hundred lines of code. The students really appreciate the existence of comments >and meaningful variable names then. Also, the program tends to serve as an >example of the type of commenting and style I expect from the students' >programs. This is also good, but the reason why one does such stuff should be clear. >Warren Harrison >The University of Portland The suggestion follows: Split the course assignments in two phases. Phase 1 is "learning the language". In this phase they learn ALL the stuff they will need. Standard trivial assignments are handed out, and marked mainly for correctness, with small penalties for style and comments. State this up front: "The purpose is to get running programs. This will teach you the language. But realize that these are TOY PROGRAMS, and as such are not to be interpreted as stuff you will see in real life." Prove this by bringing in the source for a nice big chunk of code. Like the kernel of the nearest available OS. Phase 2: Give them a hard assignment that you couldn't do in the time allotted. To be fair, tell the students this well in advance. There is no sense in treating them like children. Give them the straight goods. "This assignment is vicious, rough and nasty. It's designed to show you how little you know." Make it look superficially simple. Then mark it as if they were all grads. No mercy. Threaten that people who hand in nothing (or null answers) fail the course. (A threat which you won't carry through, of course) Hand it back at the beginning of class and wait for the disappointed silence. Then solve it in 3 minutes. (If you can manage it. Getting something that the uninitiated can't solve and that you can explain in no time will be tricky.) This will demonstrate the following: 1) Programming isn't coding. Programming is also high-level design. 2) Discipline pays benefits. After all, you did in 10 minutes what took them 1 week. 3) They now know the language much better than they did before. Clearly this is a left-field suggestion, but I have found in my experience that people operate to your expectations, and usually no higher. Make clear that you aren't going to take garbage, and people likely won't give it to you. The purpose here is to issue a challenge that everybody will take seriously and that everybody will accept. To have "wimped out" of the challenge must be seen to be the lesser option. (Obviously, you must leave escape routes for illness and other extenuating circumstances). The challenge must have a purpose, which is in this case to teach people the importance of discipline. It will also help them see the difference between the toy assignments you handed out earlier and the real stuff they will see during employment. Part of the reason the phrase "real world" comes up in the paragraphs above is that I found when I did my undergrad that I learned more from my first co-op work term (after 4 months of school) than I did in the first two years of university. Unfortunately, most university students in CS take bullsh*t summer jobs, and never truly experience the relevance of what they learn until some years later. At my grad school, I am constantly surprised at how little experience the undergrads and even some of the grads have. To compensate, and to make the students understand, real problems must be presented and attempted in class. BUT: Real efforts must gain real rewards. The one or two students who do well on the satanic assignment above must be amply rewarded. Exemption from the final exam or a can't-lose final must be the reward for excellence in the assignment. All students who did significant amounts of work in the assignment should receive surprisingly-high marks when they are recorded (versus the number on their paper). At one point in my undergrad years, I toyed with the idea of switching to Philosophy from CS. (I didn't) The reason being that there was a discipline in Philosophy that was being taught semi-explicitly. The "technology", so to speak wasn't important, but how you thought about it (various philosophies) and how clearly you explained them WAS important. In CS, the discipline of thought is not explicitly taught, and I think it should be. Discipline should be explained because it buys you far more than any other aspect of the technology. In particular, the details are not important, but the way of thinking is very important. The details of Quicksort are boring. The approach of Quicksort is a general algorithmic techinque that should be given much more exposure. Somewhere in Computer Science, in the miasma of algorithms, techniques and implementations, there are a few principles struggling to get out. If taught the principles, the new student will hopefully find the details of an algorithm to be simple, and readily producible. The problem is that Computer Science isn't really science. Math isn't science either. Math is philosophy (in the broadest terms). CS is also philosophy, to some extent. The major difficulty being that people see CS simply as technique, and that solving its problems is something to be done simply by dint of hardware and software engineering. I think that there's a lot more to it than that. Witness the failure of AI to be anything more than technique and boiled-down examples with funny names that do fairly simple tasks in straightforward ways. Witness Parnas' answer to the question "Can you tell me what is a module?" (Answer paraphrased) "Of course I can tell you! I teach a whole course on it!" Well fine. But there is clearly something more going on here than, "Well, use it. It works". Parnas' lack of a succinct answer to this simple question indicates to me that perhaps more thinking about thinking should be going on, probably at the expense hacking for a solution for a specific problem. -- Chris Shaw cdshaw@alberta.UUCP (via watmath, ihnp4 or ubc-vision) University of Alberta CatchPhrase: Bogus as HELL !