Grading reports
Tuesday, February 3rd, 2009I've spent today grading reports from my "applied programming" class. This is really hard work.
It is not that the reports are particularly bad. They are better than I expected. Still, correcting all of them and doing my very best in being fair in how to grade them is a lot of work.
I base the grades mainly on the code they have written, not so much the report they've written about it. After all, the class was on programming, not technical writing.
I thought about writing a test suite I could run their programs through and then base the grades on that, but many of the problems they've had in the code I've corrected so far wouldn't have been caught by this. Stuff like storing numbers as strings and casting them back and forth between strings and numbers when doing arithmetic.
As a side note, I'm very confused about why they do this, but prefer to think that one or two of them came up with this solution and the other copied it, rather than believing that so many could be confused about strings and numbers...
Anyway, stuff like this prevents me from automating the grading.
Now I've come up with a scheme where I initially assign 100 points to each sub-task they've had to solve, and then subtract points for each error (and in one case added points for a particular nice solution). I subtract 5 points for minor issues that affect the running time (in minor ways) but not the correctness. 10-15 points for errors that the should have avoided with a little thought, but again that do not affect correctness. 25-50 points for errors that leads to incorrect results (with the number of points varying depending on how unusual the conditions have to be to trigger the error), and 25 points for not testing obvious special cases in their test suite. 100 points are removed, of course, if a sub-task is not solved at all, or when it is wrong on all (common case) input.
The main problem with this approach is that there are a lot of subjectivity in which category I put an error in, and while I can argue for each case, I have to make absolutely sure that the same error always costs the same number of points.
So I have a list of common errors and their penalty, but whenever I spot an error I haven't seen before, I have to go back and look at the previous solutions to see if it is also there... so I keep looking at code I've already corrected over and over again.
I can copy and paste the corrections as I collect more and more errors, but having to go back and check the other reports from time to time is slowing me down...
I need to come up with a better way of grading for next time I teach the class...
--
34-56=-22