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
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.
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.
I had an experience with this recently. I tend to help some students out with programming to the extent that I am able and one way I do this is to print out a copy of my rough code that works but is messy, no comments, error checking, etc. I use this as an example as one way to solve a problem. I was then letting them keep this hard copy as a reference item for them to refer to and help them with their own solution.
This comes natural, it is how I learned C, by reading others source code and figuring out how it worked and adapting it to my own. Come to find out one of the students took this code and added their name to it and handed it in. It was not the same as my final code but the professor was able to see the commonality right away. She spoke to me about it in private and I explained what I was doing and how my code got out. She asked me to continue helping others but not to give them access to my code.
I feel that while she is correct in this request and I will abide by it, simply for the fact I don't want any academic repercussions I still feel that what I was doing should not be considered cheating. The person who turned in my code was blantly guilty and I am very offended and disappointed in them but one bad person doesn't ruin the system in my opinion. School is about learning and this was how I learned and how some others learn as well, within reason I feel sharing intermediate code and solutions should be ok.
When I have a project to do for a programming class and I don't know where to start, I will generally go online and google for a similar program and see how this person wrote and designed the solution. I then use that as a jumping off point. Cutting and pasting code is wrong and I would never do that but reviewing similar code written by another person is a great way to bring fresh ideas to the table or to help you think about the problem in new ways. When I turn in my code everything is commented and structured the way the professor wants and if so asked I am more them happy to explain why I choose this method and how it works.
This would never work on written exam and if you just copied code from others or the net all semester long it will be a painful exam and you will most likely fail. It is this reason why I feel no moral guilt in sharing my code to all that ask. You can copy all you want but if you don't understand what it does then sooner or later it will come to haunt you.
In my APCS class, I often share my code with others after the project is due, at which point it doesn't matter much if they copy it. Usually, my solutions are so foreign to them, they don't quite understand anyway, so they would have a difficult time explaining. I think copying code is fine, if and only if you can explain it.
But then again, there are times when you don't even want to explain code that you copy. I might include a library to help out with something and that is my only solution a hard problem, I might never find a hand-made 100% my-own solution for it. In situations like that, acknowledgment of library use is the best case, because this does happen in the real world.
I think the understanding of code is the biggest indicator of copying. If you understand and can explain it, then it is fine.
I gave out copies of two articles on Stanford and tomorrow the students are going to write a 1 page paper about it. Not sure just yet how this is going to go but I wanted to bring it to their attention. If it goes well I will have my other 1st years do it also. As to coping code, I let the students help each other if I can't get to them first. But they have to understand/explain what is going on or they get the "So what happens when they can't help you on the test?" or "So that's one grade for two of you? Hoping for that 50 then?" speech. By this time of year we do a pretty good job of peer tutoring so the "Cheating" is next to none.
I had an interesting but short conversation about this with a professor from a large state university today. His comment was along the lines of "is there more cheating in computer science or is it just easier to catch cheating in computer science." It's an interesting idea. It is frequently pretty easy to catch cheating especially with software out there that faculty can use to look for duplications. What do you all think? Are more CS students cheating or just more getting caught?
Looking at your list I was pleased to find that we have policies in place to address pretty much all of them.
We have 170 students in the first year. Howver, we still manage to find time to sit down with each student and have them present their work for assessment. We find that when students know in advance that this is going to happen they are much less likely to try to pass off work as their own. Their deliverable is broken into essential behavior (do this and you get a pass) and optional components (do this for extra marks). We try to stop students adding optional items to their solutions until they have met the essential requirements. We also give extra marks for code quality.
Finally we have a set of exercises that we rotate over a four year period, and tweak the deliverables each time so that the previous version would not pass the assessment.
This seems to work for us.