Comment by spacemanaki | Hacker News Reader

Comment by spacemanaki | Hacker News Reader

I would love to hear that there are CS/EE programs using version control to catch cheating. It seems to me that if you forced students to "show their work" by having them commit to their project repo in small increments, it would obviate (some of) the hoops some depts seem to go through to prevent cheating.

At my school, we were given programming problems a week in advance, told to solve them and memorize the solutions, and then had to show up at a computer lab for an "exam" where we basically typed the programs in and made sure they compiled, etc. I believe this process was put in place after rampant cheating was happening in more traditional "turn in your source code" types of projects. However, this was a pretty horrid experience, and for some students who treated them like regular exams (ie didn't actually memorize working solutions beforehand) these exams were crushing to their grades.

I can imagine some sort of automated checker for this, examining repos for unusual activity (one giant commit right at due date) after a project was submitted. Of course, I've also heard that in some academic CS depts, any version control at all is a huge deal (we were taught how to use the integrated CVS tools in Eclipse in one afternoon by some TAs, and that was the extent of my exposure to vc in the classroom, and this was in 2006-7), so maybe I'm dreaming too much.

I tried to use this approach last semester in a course I taught and found out that it isn't easy to get used to an SCM the first time, so regular and good students end up doing huge and late commits, moreover, one of the worse performing students learnt -ironically- to alter the git log to seem more diligent than he actually was (lots of commits and files changed), and with stuff like git rebase, a more clever cheater could never actually get caught. So an approach strongly reliant on the SCM kinda weakens in practice(though, as you point out, it could be used as a _secondary indicator_ or guarantee of work). And in theory, as other commenters say, taken to extremes, one ends up evaluating secondary things and overseeing essential things like the ability to rationally defend the code and explain one's approach.

Nevertheless, it is feasible to set up stuff like post-commit hooks (I actually used 'em to monitor the turn ins to an exam) to maybe submit the code to an automated plagiarism detector like [moss](http://theory.stanford.edu/~aiken/moss/), that would be cool, maybe I'll try that out next semester.

Yeah, there are definitely a lot of things I didn't think of which would make this somewhat ineffective.

> one ends up evaluating secondary things and overseeing essential things like the ability to rationally defend the code and explain one's approach.

This seems to describe exactly the problem with the exams I had, which tested more the ability to memorize a solution and regurgitate it in a test setting. This is of course anecdotal, but I've heard of similar exams in other schools. So I think there's a lot of room for improvement there.

"I would love to hear that there are CS/EE programs using version control to catch cheating. It seems to me that if you forced students to "show their work" by having them commit to their project repo in small increments, it would obviate (some of) the hoops some depts seem to go through to prevent cheating."

I know several professors that attempt this. The work-around is pretty trivial though: just cheat as usual, then claim you forgot to commit until you were already done. The best the professor can really do in those cases is dock the kids a letter-grade or so (oh noes, a B!), since forgetting to commit is at least somewhat plausible for students unused to version control, and certainly isn't strong evidence of cheating.

Of course the really bad cheaters are still caught, but through the tried and true method of comparing code and looking for students that don't understand their own code.

> The work-around is pretty trivial though: just cheat as usual, then claim you forgot to commit until you were already done.

The Workaround for this is likewise trivial: make "failure to show work" grounds for a failing assignment grade.

That requires professors to be much "tougher" than they often like to be. Completely failing an assignment for reasons not actually relating to the content of the assignment is pretty unpopular here, among everybody.

It's also not impossible to fake a revision history (in fact, it's pretty damned easy), so if you start flat out failing kids only the honest students will get "caught".

> That requires professors to be much "tougher" than they often like to be.

If a prof/TA can't be bothered to police their students then they forfeit any right to complain about cheating.

If students can't follow directions (give grace on the first offence, maybe) then letting them slide does a disservice to their future.

As for cheaters: I don't mind whether or not really determined cheaters can sneak through. They are only cheating themselves in the long run. A system that only catches the 'honest' kids is still a good system because only the 'honest' students will generally make any attempt to mend their ways.

just my $.02

profs/TAs certainly can catch cheaters though, and they're pretty good at it without resorting to extreme measures.

Instantly failing anybody who isn't comfortable with version control is the type of scorched earth tactic that you'd expect the TSA to dream up if they were in charge of catching cheaters.

I am not advocating any sort of Zero Tolerance policy (e.g. "instantly failing") for this. In fact, I think ZT is insane in most if not all cases.

For the purposes of this discussion (which was about having students use version control for assignments) using version control is as central to the requirements as implementing the algorithm and using the assigned language and failure to follow instructions can, at the instructor's discretion, result in grading penalties. As a bonus, this adds another hurdle for cheaters to clear and provides another opportunity for profs/TAs to notice anything suspicious.

Hope that clears some things up...

> That requires professors to be much "tougher" than they often like to be.

In my case, students were being failed (actually, given 0 credit) because the solutions to the exams wouldn't compile. That's pretty tough, I think. Especially for CS 101.

Eh, in CS 101 getting you program to compile is basically the entirety of the assignment. I think it's pretty unrealistic to expect TAs to spend time figuring out why you couldn't even get your program to build, let alone work.

Reply on news.ycombinator.com