Path: utzoo!mnetor!uunet!ncc!alberta!cdshaw From: cdshaw@alberta.UUCP (Chris Shaw) Newsgroups: comp.software-eng Subject: Re: Soft eng in 1st yr classes.. pontification Message-ID: <1204@pembina.UUCP> Date: 7 Apr 88 23:35:06 GMT References: <555@psu-cs.UUCP> <1434@ur-tut.UUCP> <3415@bunker.UUCP> <5359@utah-cs.UUCP> <36845UH2@PSUVM> <563@psu-cs.UUCP> <1167@pembina.UUCP> <2330@uvacs.CS.VIRGINIA.EDU> Reply-To: cdshaw@pembina.UUCP (Chris Shaw) Organization: U. of Alberta, Edmonton, Alberta, Canada Lines: 118 In article <2330@uvacs.CS.VIRGINIA.EDU> hsd@uvacs.cs.virginia.edu.UUCP (Harry S. Delugach) writes: >In article <1167@pembina.UUCP> cdshaw@pembina.UUCP (Chris Shaw) writes: >> >>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.) >>..... >>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. >If this is what your "experience" has taught you, then it is a sad commentary >on the state of things in the "real world". Perhaps some of the conditions >you are trying to simulate are a source of its problems. My experience tells me that there are big problems that one person can't possibly solve. There are medium problems that are huge amounts of work, and there are small problems that are lots of work if you don't know which way is up. And then there are tiny problems which anyone can do. By the way, I mean self-discipline: discipline of thought. I do not mean to imply some kind of grade-school detention schtick. Nobody codes isolated tiny problems for pay, except TA's for first-year courses. The purpose of assigning tiny problems is to illustrate the use of particular language features. The purpose of the "vicious problem" proposed above is to illustrate that the tiny problems are toys, are purely illustrative, and have next to nothing to do with "real life". Tiny problems are the nails with which one builds a house. They are not the house. You will find only a few first year people who believe this, however. >The almost belligerent attitude recommended for the instructor-to-be >sends the message to students that "the real world is cold, heartless, >loathe to communicate and cooperate." Sure, there are plenty of places >where this is true, but rather than teaching software engineering as >a "discipline" or a set of survival skills, why not demonstrate the >positive value of communication and cooperation? Unless you think they >don't really have a positive value? Co-operation on tiny technical problems serves no value whatsoever. Such problems are so small that it makes sense for only one person to solve them. What does co-operation buy you? In a group of N people, it's 1 worker and N-1 people watching. This teaches the value of sponging. Believe me, I know full well the value of sponging, and in the many group projects I did while an undergrad, in all but one I did most of the work, and in 1 I did the least. I felt just as bad not having done enough as having done too much. In some projects, there was too much work for one, and in other projects there wasn't, and in the latter projects, groups were inappropriate. The nasty problem should show that a disciplined approach will reap tremendous rewards. It should show that ad hoc techniques will get you there slowly or not at all. It will show that writing little programs is not like writing big ones. It will show that software engineering IS a discipline, just like any other engineering. The problem being that its principles are not clear. I believe it is CRIME to let people off easy and to expect little of them in University. What the hell IS a degree, anyway? To me, it is preparation. It should not just be the reward of being a middle-class son or daughter. University is a place where people fail. It's where you can find whether or not you have what it takes. It hopefully should show the value of HARD WORK. (Sorry, I'm getting out of hand here). Of course, real life does all these things too, but real life tends to lack guidance or standards. >If you want to simulate the real world to teach software engineering, >then have a two-semester, full-time course, where students are taking >nothing but your course. The high degree of commitment to a course that the >disciplinarians require (approximating an employee's commitment to his >employer) is not possible when students are also involved in other >courses. The problem was vicious because of the amount of thought required to solve it completely and correctly. I suppose that I must back down on some of my original statements above, in particular, the bit about the instructor not being able to solve it in the time allotted. That statement implies very large code volume. I suppose the guide should be that the student should be able to solve the problem fairly easily by the end of first year, given less than a week of 4-hour days. But my main message is this: Don't let University students delude themselves into thinking that University problems are the same as real ones. Even the vicious problem is ultimately a toy. Never let them have the chance to whine "but it was never like this at U of X". They will already know this, and they will be ready for it. As for the perfectly valid point that a "disciplinarian" course requires time, it's important tell students in advance that there will be a large time commitment at one point in the term. Requiring this commitment for the entire term is out of line, which is why there is ONE vicious problem, not 4. >Harry S. Delugach University of Virginia, Dept. of Computer Science Somebody else mentioned that as an adult student, he didn't like the concept of mind games, because he already knew what real life was about. Well true, but clearly some of the tactics mentioned in my previous posting were to motivate young folks who might feel otherwise disinclined to bother. Such stuff is probably inappropriate with people over 25 in a classroom setting, simply because such students will do what you ask, and will believe it when you tell them that the toy problems are toys. The vicious problem supplies a young person the proof that s/he no doubt desires. If you tell them that the problems they have done to date are toys, and they have done them with some struggle, they won't believe how hard real stuff can be. The vicious problem shows them. -- Chris Shaw cdshaw@alberta.UUCP (via watmath, ihnp4 or ubc-vision) University of Alberta CatchPhrase: Bogus as HELL !