bmg@mck-csc.UUCP (Bernard M. Gunther) (09/26/85)
I was Lab TAing a software engineeering course a few years ago with a grade breakdown which went something like this: 4 Minor Projects - 40% Final Project Design 10% Implementation 10% Midterm 15% Final 25% The final project was a 5 week 3 person implementation of a text editor or a spreadsheet or whatever project they had that year. The implementation of the final project tended to take ~100+ hours per person over 3 weeks. This was the most rewarding part of the course - working in a team to get something accomplished, and yet it just wasn't worth it because of the disasterous effects if had on all the other courses you were taking. Isn't this a little wrong. A 3 hour exam should not count more than 100 hours of difficult work.difficult work. Bernie Gunther
usenet@ucbvax.ARPA (USENET News Administration) (09/29/85)
> [ ... much deleted ... ] The implementation of the final project >tended to take ~100+ hours per person over 3 weeks. This was the >most rewarding part of the course - working in a team to get >something accomplished, and yet it just wasn't worth it because of >the disasterous effects if had on all the other courses you were >taking. Isn't this a little wrong. A 3 hour exam should not count >more than 100 hours of difficult work. [ ... more deleted ... ] Things like that happen here also. I think that one of the reasons it happens is that so many students are so desperate to get into CS that they will put up with this kind of thing. It could be looked at as part of the "push 'em to the limit" philosophy that appears in various places ( i.e. some graduate schools, basic training in the army, exploitive economic systems ...) I think the underlying principle is that if there is some "carrot" or "stick" the powers that be have to offer, a system can be set up whereby the underlings compete with each other to get the carrot or avoid the stick, and by competing push their limits more than they would do normally ...
mash@mips.UUCP (John Mashey) (10/01/85)
Bernie Gunther writes: > I was Lab TAing a software engineeering course a few years ago with a grade > breakdown which went something like this: > 4 Minor Projects - 40% > Final Project Design 10% > Implementation 10% > Midterm 15% > Final 25% > [much deleted].... A 3 hour exam should not count more than 100 hours of > difficult work.difficult work. > This is a hard call, and seldom has an obvious answer; I used to struggle with it when I taught. [In a former life, long ago, and far away, I used to teach operating systems courses using IBM BAL and OS/360. They had heavy programming assignments, and were consistently voted "most overwork per credit" in student ratings.] Anyway: 1) If a course is more software engineering than computer science, its meat is usually in the programming projects. Hence you must give reasonable hunks of credit for the work put in. It also helps to give out all assignments at the beginning of the term so eager beavers can get going. 2) It is, sad to say, easier to cheat on programming projects, and it is often difficult to grade multi-person projects, even though they can be an important part. Exams provide a good check-and-balance for a) covering material not covered by projects b) catching cheating. 3) I generally used a project<->exam weight of 40-60 to 60-40, and this seemed to work pretty well, especially if a few important questions on the exams were keyed to people's understanding of what they'd done on the projects. Also, it was important to catch cheating. If you're going to make people work like crazy, you'd better make sure you nail most of the cheaters. I found that a good model was the "inverse normal curve", i.e., lots of A's, B's, and F's, very few C's or D's. If people got thru the coruse in any creditable manner, they got A's or B's. If they worked hard and barely scraped through, they got a C. If they didn't do any work, or if I caught them cheating, they got an F. In general, good software engineering courses with heavy labs are HARD to teach, and often thankless tasks. It is HARD to create good programming projects that vary from term to term, are useful, instructive, and OK to grade. Be thankful if you get a good course. Tom Tedrick writes on the same subject: > Things like that happen here also. I think that one of the reasons > it happens is that so many students are so desperate to get into > CS that they will put up with this kind of thing. It could > be looked at as part of the "push 'em to the limit" philosophy > that appears in various places ( i.e. some graduate schools, > basic training in the army, exploitive economic systems ...) ..... This is an interesting theory, and may be true. Sometimes such courses are informally used as "gateway" or "weed-out" courses, i.e., required courses in the middle of required sequences, such that a) everybody knows they're hard. b) success in the course probably indicates that people will do OK later c) an appropriate fraction of people will not make it thru, and will probably switch majors shortly thereafter. Having such things may seem heartless. In an ideal world, there would be free high-quality education for everybody in any subject they want. Given the real world, with university budgets as they are, and especially with computer science viewed as a glamor field, it is hard to be ideal. I tend to believe that if you think you need "weedout" courses, it is best to have them in the middle, i.e., you don't want introductory courses to be brutal, because you want people to get a chance to get started, and you want to avoid a total influence from previous background; on the other hand, it is cruel to make the last course a weedout. As a related example, consider someone who passes such a course by the skin of their teeth, struggling hard. Depending on the circumstances, it may be kinder to tell them privately that they passed, but that they should seriously consider another major, or shift in emphasis, or something, because it is, after all, a competitive business, and there are NOT good programming jobs for everybody who wants one. This is not a fun thing to do; it is easier to just post the grades. -- -john mashey UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!mash DDD: 415-960-1200 USPS: MIPS Computer Systems, 1330 Charleston Rd, Mtn View, CA 94043