[QUOTE=commasense]
Monstre: thanks for answering my question. My point was whether you make an effort to guard against your own confirmation bias by subjecting all (or at least some) students to the same checks as those who seem obviously to be cheating. I don’t doubt your ability to detect cheating, but you might be at risk of relying on it too much, and get fooled by really good cheating, or by someone whom you would prefer not to suspect. You could protect against this by Googling everyone’s code, or by randomly spot checking a certain number, even if they didn’t set off your internal detector.
[/QUOTE]
Right, and I understand your point. And on assignments where they are all writing to the same specifications, I do run them all as a batch through that program I talked about. In this particular Java game project, I haven’t done Google checks before – but in the usual context of this course (these are students who I’ve mostly had before in my C++ class, and this term, they all were), I’ve felt that my Java students had already proven themselves as students who do their own work. Maybe it’s time to start spot-checking (with Google) the code on these assignments after all.
As for students getting away with it – I’m sure there are some who manage to slip under the radar on some assignments. But over time, the way I’ve adjusted to deal with that is to structure the course grading scale to minimize its benefit. If they “ace” the assignments but bomb the tests, they aren’t passing the class. And I write my tests so that any code-writing questions are asked in a similar format they’ve seen on assignments. If they didn’t do their own work on the assignments, they are pretty much going to blow those test questions.