Cheating In Computer Science Classes

  • Article

This story on cheating in Computer Science classes is one of  those things that really makes you think. Years ago one of my students was so tired of students looking over his shoulder and stealing his code that he started using variable names that made absolutely no sense at all. He figured that if they were too obviously his no one would dare steal his code. This was my first awareness of student cheating in my own classroom and was a real eye opener. I kept a close eye on things but honestly I am sure I missed as much cheating as I caught. Hopefully not more but who knows?

Defining cheating in computer science / programming courses is difficult though. After all code reuse is a goal for professional developers and team work is essential. The article above listed HONOR CODE RULES FOR STANFORD'S COMPUTER SCIENCE CLASSES and they are a lot like I tried to run things in my classroom

  • You must indicate on your submission the receipt of any assistance, such as discussion of ideas and strategies and write the actual program code on your own.
  • You must not share program code with other students.
  • You must not look at solution sets or program code from other years.
  • You must be prepared to explain any program code you submit.

The last line became a critical part of my final project grading in my courses. I would do a one on one interview and mini code review with each student and we would go over their project together. I would prepare questions about code that seemed tricky or overly familiar to me. I would ask for explanations of names and program organization. All this to make sure that students understood what they had done. This doesn’t scale well of course. You can’t realistically do it for a 180 students. I wish we could but there is a limit to time in the day. On smaller projects during the year I would do spot interviews when I suspected something was “different” about a project. This requires knowing what each student is like and also doesn’t always scale. But you know English teachers do it with writing projects so we should be able to do it in computer science classes as well. Style is unique.

But the article also says that cheating is much more common in computer science courses than in other courses. Why is that? Stanford’s Eric Roberts has some ideas based on his research.

  • Students are attracted to a computer science degree by its marketability and as a steppingstone to wealth and job security rather than intrinsic interest in the subject. They see stellar course work as critical to their future livelihood.
  • The material is cumulative, so students who neglect early work are completely confused by later assignments, and panic.
  • Unlike other disciplines, it is not possible to merely submit inferior work. A computer program that doesn't work is simply rejected, which creates student anxiety.
  • It"s easy to get help from others. In terminal clusters, students work near each other, so it’s tempting to ask for help, peek over a shoulder or retrieve program listings from a recycling bin. Many students accidentally leave copies of their work on the hard disk of public machines.
  • Computer science courses often reuse past assignments, because assignments, like programs, improve with time and debugging. So students seek solution sets from past course offerings.

These resonate with me. Take the second item. How do we handle it when students fall behind? Can we do things more self-paced, especially in the early courses, to make this sort of cheating less necessary? Perhaps not at college/university but perhaps we can in high school. Helping students get a solid base for later seems like it should be a huge goal for HS CS.

And the third item. Do we have to make projects binary – pass or fail? Or can we review code and give some partial credit for it? That is done in grading the free response questions on the APCS exam. This is a larger problem with projects/homework of course. But I tried to review even code that would not correctly compile to at least understand what the student was not understanding. If we can review projects while they are being worked on we can help with those sorts of things. Again, not easy to scale but doable in smaller courses. And lets face it, small classes are what many HS CS teachers are facing. Perhaps we can turn that into an advantage for our students.

Clearly this is going to be an issue going forward. It means we need to talk about the ethics of “helping”, “borrowing” and other cheating methods. But we also need to emphasize that students really need to and should want to learn these things for themselves. Success in later their life will depend on what they know and not on what the student in the next chair knows.

BTW see Mark Guzdial’s take on this at Stanford finds cheating increasing, especially among CS students and how cheating influenced Georgia Tech in how they rewrote the curriculum. Useful information and ideas.