About the same time, a massive cheating scandal was uncovered at the University of Central Florida involving 200 students who cheated on their midterm exam (approximately one-third of the class). And just a few weeks before I had read that cheating in CS accounted for 23% of all honor code violations at Stanford University where the students involved in the cheating make up only 6.5% of the student body. Oh, and did I mention the article in the Chronicle of Higher Education about the "Shadow Scholar" who has cashed-in by written innumerable papers on behalf of college students?
With so much cheating going on, one can't help but wonder if students today value honesty less than previous generations or is it just easier to cheat (and catch cheating) today? Is there something we could do as CS educators to reduce the amount of cheating going on in CS?
On Monday my chairman placed an article in my mailbox entitled Cheating in Computer Science by William Murray, a faculty member at the Naval Postgraduate School who is well-known in the computer security field. Murray thinks current CS teaching practices in which students must write original programs actually promote cheating by creating an artificial problem for which cheating is often the easiest strategy. Instead, Murray suggests we should employ practices that de-incentivise cheating, perhaps by promoting skills which are highly valued in the workplace like code re-use and teamwork.
I certainly agree that code re-use and teamwork can have positive benefits when learning programming. Pair programming is something I've been using for several years with positive results. I also promote limited code-reuse in my upper level courses when it's code that can augment my students' final projects, as long as the reuse is documented thoroughly and the re-user can adequately explain the code she's reused.
However, I don't see code re-use or peer programming as a panacea for reducing cheating. When I questioned my student who was caught copying code from the Web, it was clear that he didn't really understand what he had copied. He didn't understand it enough to even be able to fashion it into a solution resembling the program specification I had given. How did code re-use help him learn anything? I'm not saying he could not have potentially learned something, just that code re-use is not an immediate fix for cheating.
Teamwork is also not an immediate fix. I still remember vividly during my undergraduate years working on a team with someone who was understanding the class material significantly better than the rest of us. We relied on him heavily to get good grades on our projects, and many times we failed to fully understand our (his) solutions to the problems. And in pair programming, there are times when the weaker partner is just not going to "get" what is so obvious to the stronger partner, and it's easier to just turn in the finished assignment rather than struggle with the solution individually.
Murray goes on to suggest how teaching programming skills using existing programs will somehow remove the incentive to cheat:
"I no longer teach programming by teaching the features of the language and asking the students for original compositions in the language. Instead I give them programs that work and ask them to change their behavior. I give them programs that do not work and ask them to repair them. I give them programs and ask them to decompose them. I give them executables and ask them for source, un-commented source and ask for the comments, description, or specification. I let them learn the language the same way that they learned their first language. All tools, tactics and strategies are legitimate." (emphasis mine)Let me get this straight: a student can use the strategy of copying someone else's solution, cite the person who did all the work developing the solution, and get credit for the work? Surely this is not what Murray is advocating. These are certainly worthwhile approaches that students could learn a lot from, but Murray does not make it clear how these approaches are less resistant to dishonest practices.
Murray later states that "Nice people do not put others in difficult ethical dilemmas," suggesting that I am somehow a mean guy for putting my students in a difficult situation when I ask them to write original code. I'm sure some of my students would agree when they start working on their assignments just hours before they are due. Perhaps every department on campus is guilty of the same thing since we all create "artificial" situations where students must come up with original solutions instead of borrowing others'.
My goal is not necessarily just to be nice, but to hold my students to a level of rigor where, if they take it seriously and put in the time and honest effort, they will be well prepared to enter the job market and have a basis of knowledge from which they can learn new skills. Many times this will require original work to problems that others may have already solved. However, having students solve these problems on their own or in pairs will put their brain through a mental workout that will prepare them to be a productive member of a development team in the future.
So what can CS instructors do to make cheating less appealing? Coming up with new assignments that are engaging, changing exam questions, and all those other time-consuming tasks are certainly beneficial. But I think a more successful approach is to simply make the case for academic integrity as a relationship between teacher and student, a relationship that can be harmed when deceit is allowed to enter the picture. Deception will potentially harm the student's self-image more than anything and cause serious regrets in the long-term. For those of us that seek to follow God, the relationship is three-way, and deception in a relationship with God is a non-starter.
I think we have to realize that many college students are still quite young and lack the maturity to take the high road. Our job as faculty is to help those who mess-up learn from their mistakes and exhort them to exercise integrity in the small things and the big things. This is something I'm still learning to apply to myself.
