The best however, is a 1:1 code review with a TA or Prof. Randomly jumping to files, reading the code and asking questions about it. Extremely hard to copy a codebase and learn it well enough you can explain it but really easy to do if you wrote it yourself.
re the 1:1s with TA/professor, I agree. if you can explain code that you didn't even write, you might be even more deserving of that A.
Sure the later can copy their assignments. But once they'll hit a non-trivial assignment or a code review in a more advance class they won't be able to fake it anymore. You are just delaying their transfer to another major. And that gives the CS department one extra course they can collect tuition from and justify hiring TAs for...
The sky's the limit when you think about it really.
1) Version control all assignments. I force them to make periodic commits throughout the week. If they want to copy a project wholesale, they have to do so in a way that takes a lot of time and effort.
2) Comparing bytecode. If they change the names of variables, comments, spacing, etc. these superficial differences will be lost in compilation.
3) Oral explanations. Now that everyone has guaranteed access to screen recording software, I force my students to record an explanation of their work. They go through their code line by line and explain it to me. I can tell very quickly when a student is explaining code they haven't written. If they are explaining code they haven't written to a satisfactory degree, then they've at least demonstrated they've learned something.
4) Remove incentives to cheat. Give them all the resources they need and more than enough time. Provide easily accessible venues like chatrooms and forums where they can ask questions anonymously. Provide opportunities to improve prior poor grades so they feel like failure is okay.
This doesn't eliminate cheating 100%, but from my experience it does seem to cause cheaters to fail, as their cheating does not pass for acceptable work. The students who earn an A come to see me during office hours and I know they are doing the work. I would say very rarely does someone earn an A who is not on my radar as being an obvious high-performing student. If a student is cheating and earning an F or D, I can't say I care much about that.
Notice none of these methods involve an invasive surveillance regime. I don't require cameras on at all time, 360 degree views of work areas to prove no one is helping, software to monitor tabs and processes... all this is completely futile. The students hate it and it incentivizes them to find ways to thwart it. They feel justified in doing so. I saw one post that advocated running a high speed fan to drown out typing noises, wearing reflective glasses in a dark room to foil eye tracking software, putting Vaseline on the camera... all to what end? To cheat on a psych exam? It's an arms race that's not worth fighting. The solution here is to adapt teaching methods with new technologies and testing methods.
Not everyone does projects over time, not everyone commits all the time. I don't like committing in progress work and I usually do work in big chunks with large breaks in between, especially for solo projects where I don't have to share code regularly with others.
Based on your criteria, I'd likely be considered a "possible cheater" just for having a different style.
Regardless though, my students usually are at a point where they don't have a commit style. They come to my class with no knowledge of git or version control -- I have to teach it to them.
Secondly, labeling you a possible cheater doesn't condemn you to anything, it just puts you on a shortlist of assignments to examine more closely.
Thirdly, this style of committing has helped more than a few students out when their computers die mid assignment and they need to move to another computer. It also allow me to help them with their assignments. When they come to me for questions, the first thing I ask is "have you pushed everything to your repo?" Instead of trying to debug over a virtual desktop connection, I can run their code locally and get to the cause much quicker in my own environment. It really works out well for everyone involved.
Question: if (when) a student hands in an assignment without the periodic commits, what happens? How do you measure & set expectations for sufficient frequency of commits? (i.e., 1 single commit is too few, I assume that once a day is enough, but where's the threshold?)
Thanks again for sharing - I'll be thinking about these for my own classes!
In terms of getting them to follow the commit guidelines, I give them a carrot and a stick. The carrot is, if they start N number of questions half way to the due date, they can get a penalty-free extension if they need more time to complete the assignment. This is to incentivize students to start early. I've found one of the biggest indicators of successful students is that they start assignments early. Students who start their assignment on the due date usually run into blocking issues (software not configured properly, computer not working right, network is down) that would be trivially overcome if they had started a day or two earlier. Students who have this habit quickly correct within an assignment or two.
The stick is by the midterm, I start requiring it more strictly by subtracting points for not following the guidelines. I think of it like a math assignment; if all you provide on a math exam is the solution, you'll get little to no credit for that. Showing your process is part of the work in math, and I treat it the same way in my classes.
Every semester, students fell into the same buckets. - Those I rarely saw who nailed everything (and were getting an A or a high B because they understood the material), - Those I saw constantly who were going to get an A or a B (because they sometimes didn't understand things from class, or when they did, wanted to make sure; or for a few, understood it all, but knew the importance of showing they cared about the material to the professor and TAs) - Those I saw constantly who were going to get a C or a B (they rarely understood from class, but were willing to put in the work to try to) - Those I never saw who were going to fail (they didn't show up to anything).
It was pretty much invariably this latter group that got caught cheating. That's not to say the other groups didn't, but they at least got working code, did really well on the exams (pre-COVID, proctored in person), and in conversation were able to show they understood, so I'm a lot less concerned about them.
I think it could possibly scale to larger classes as long as the grading team scales with it. I'm not sure how public universities handle their grader allocations.
No one wants to hear this answer because it means actual work for the teaching staff (compared to, say, automated scoring of multiple-choice tests), but it is, in fact, the answer.
It's not just "actual work", writing high quality tests and projects and then grading them is multiple full-time jobs worth of work. It's equivalent to interviewing 100 job candidates every week, forever.
Projects they had to demo, and they had a published rubric. While it was possible sometimes to play to the rubric, it still meant there was very little work to figure out a grade.
Tests, on the other hand, I had to dig in, understand what they were trying to do, figure out if it worked, and award partial credit. I guess the prof could have done multiple choice to make grading easy, but that has all kinds of problems with actually testing anything.
The fact that the university doesn't provide adequate staffing is not an excuse for short-changing the students still further.
Actual work for the already incredibly underpaid, over-worked teaching staff. As the money dries up in university funding, teachers are stretched thinner and thinner. That forces them to rely more on automated testing instead of having the time to actually know more about their students' performance. That in turn makes it easier for students to cheat.
The economics (as usual) are perverting the system. The individual participants are merely suffering from the perserve incentives of the system.
So I think I actually understand the system pretty well.
Edit: teaching is part of the job, dude. It just is. If you asked the average taxpayer (you know, the ones who pay the base salary before grant money is taken into account) whether teaching is an important part of the job, what do you suppose they're going to say?
If you don't want to teach, you need to find a job that doesn't involve teaching. If you accept a job that requires teaching, you're morally obligated to provide the best teaching you can.
Or so I see it.