March 14, 2006

A private message

To my CS 262 students, whose exam I am grading right now:

Would it kill you to read the directions once in a while? I mean, are you trying to annoy me by making it harder to test your code? Because honestly, it's usually not a good idea to actively annoy people who are trying to come up with a grade for your work. Not if you want a good grade for that work, at least. You should probably consider yourselves lucky that I'm a softie and, despite running on no sleep, am bothering to correct the simple errors in your interface so that I can assign a fairer grade for the body of the problem.

But I'm still pretty annoyed about the whole thing.

"Everyone knows the Painful Chill of Nonexistence. That's high school." --Sam Heath

Posted by blahedo at 6:13am on 14 Mar 2006
Comments

The reason you specified an interface was to make it reasonable to do the grading. Furthermore, implementing to an interface is a crucial skill in computer science. If their work does not conform to the interface, give them a zero and offer them the opportunity to resubmit it within a week with a working interface for grading at a letter grade penalty. Of course, you should make it clear that this is not their opportunity to fix bugs in the program, just the interface, and that you will be checking the differences between their first submission and their working submission.

Yes, verifying differences in the second round of grading may be a bit harder than just fixing their interfaces, but you can have a quick turnaround on the first round and, ideally, you will only have to do it once. Better yet, make it clear that each student will have this opportunity exactly once in the course, and subsequent failures to conform to the interface will result in a non-negotiable zero.

Yes, it's hardass, but it teaches them that a sine qua non of programming is being able to work within a design, whether it is your own or inflicted upon you.

Posted by Greg at 7:40am on 14 Mar 2006
Yeah, I've been thinking for a while now that I needed to implement a more hardass policy on interfaces. I like your idea of checking the diff to make sure they're only fixing the interface—that's one of the worries I had. Part of the problem too is that I'm also fairly lenient on giving extensions, and that I'm frequently a bit slow to actually get to the grading, both of which make a return-and-resubmit policy harder to implement.

But something needs to be done, that's for sure. Now to nail down my exact policy in the next few days, before spring term syllabi go out....

Posted by blahedo at 5:38am on 15 Mar 2006

Well, you can completely automate the return-and-resubmit part if your interface is solid enough. You write a harness that tests each submission's interface, starting with make. Run the harness on each submission, and kick back the ones that fail. You can even give this out to the students ahead of time. Then you create a harness that actually tests results for your own use in grading.

By the way, do you sandbox your grading? I mean, suppose a malicious student submitted a trojan that downloads a rootkit. Sure, it doesn't sound like a concern, until it happens.

Posted by Greg at 11:33am on 17 Mar 2006
I had some comments, but Greg actually covered most of the points. As far as sandboxing goes, probably the easiest thing to implement is a FreeBSD jail(). Posted by ansible at 11:47am on 18 Mar 2006
Valid XHTML 1.0!