Here's my solution to this:

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.

#1 just encourages people to make BS commits throughout the week to pad the numbers.

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.

The way I explain this requirements to my student is that the proof-of-work is just as important to me as the end result. It's like in math class: you don't just write the answer, you need to show your work. Your commit history is not distinct from the assignment, it is part of the assignment.

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.

This is for a class. How a student prefers to make their commits is not really important. If you are taking a class and the requirement for credit is doing commits of in-progress work you commit the in-progress work.

These are awesome tips - thanks for sharing!

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!

The first half of the class they are getting used to git and version control, so I don't enforce it too closely. Generally I decompose the assignments into a number of parts, and ask for at least one commit per part. e.g. Part 1, lay out your project directories. Part 2, stub out your functions. Part 3 implement function a, etc. My students are at a level where they need this granularity of direction. They get lost easily if assignments are too open-ended.

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.

Not going to comment on the listed steps (that sounds like a pain to grade), but I will totally echo your comment about knowing how well someone is doing.

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.

It's great that you run your courses that way and I'm sure your students benefit from the experience. But is it really scalable for lower division courses at public universities with high student to instructor ratios?

I've used this technique over 3 semesters so far, with a total of 500 students. My team is myself, a TA, and 10-15 undergraduate graders. I try to triage grading with automated tests and a bunch of tools to give me an overview of how students are doing their work (looking at the first and last commit, commit frequency, etc.). The most work is in assessing the oral assignments, but I actually like doing those the most - I get to hear from my students in their own voice, which is nice during this isolated pandemic.

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.

Which presumably is why a lot of mine also included demos followed by questions about the implementation.

Projects also need to change dramatically year after year or else people will just get the project from the year prior.

They can change slightly (even if someone gets the project from a prior year and modifies it a bit, that still requires understanding), or they can be open ended enough to be obvious if someone directly cheats (i.e., the 'create a game for the Game Boy Advance' project I had)