Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!ames!ptsfa!ihnp4!inuxc!pur-ee!j.cc.purdue.edu!i.cc.purdue.edu!arthur.cs.purdue.edu!narten
From: narten@percival.cs.purdue.edu (Thomas Narten)
Newsgroups: comp.edu
Subject: Re: Cheating on Programming Assignments
Message-ID: <1254@arthur.cs.purdue.edu>
Date: Tue, 21-Apr-87 12:10:34 EST
Article-I.D.: arthur.1254
Posted: Tue Apr 21 12:10:34 1987
Date-Received: Thu, 23-Apr-87 04:04:46 EST
Sender: news@arthur.cs.purdue.edu
Organization: Department of Computer Science, Purdue University
Lines: 60

Catching cheaters is not black and white. Or rather, catching cheaters
is easy. Doling out appropriate punishment is not black and white.  If
you think otherwise, you haven't dealt with it in all its forms
before.

Several years ago, I wrote an electronic submission facility that was
used for an intro Fortran course of about 1000 students. One thing it
did was compare all programs to one another. The program was very
simple. Basically, it counted occurences of certain things (e.g.
number of distinct variables, numbers of certain control structures,
etc.). Stats were collected on every program, and when the results
were in, all the data was combined and every set of data points was
compared to every other set. There was some leeway in what was
considered a match, for one thing, it was easy to get lots of matches!
Once you have matches, the programs listed as matches were compared by
hand and a decision was made as to whether they were similar or not.

In all the cases we pursued, it was *obvious* that there was extensive
"collaberation" (read code sharing). In all cases there were little
quirks that appeared in both listings.  E.g. a *very* peculiar
indention scheme, very unique ways of doing formatted I/O (that hadn't
been discussed in class), a very nonstandard algorithm chosen in
implementing a subroutine, etc. To be even more sure, we would look
for 2 or 3 such quirks before calling in the students.

In the end, we ran it production for only 2 assignments. We hauled 20%
of the students into conferences to hear their story of what was going
on. 

1) No one was willing to admit they had cheated. I mean NO ONE. The
evidence was always clear. We had enough clear cases, we didn't need
to bother with the borderline cases.

2) Some cases involved person A copying the assignment from person B
without B's knowledge. Some of these were easy to verify, person A
could not convince us that they knew anything about what their program
did.

3) By far the most cases involved friends working on assignments
together. They never felt that they were violating the rules. They
"never shared code". They "never shared pseudocode". They "never
wrote code together". They did "discuss the assignment". These cases
are very hard to deal with. 

You cannot deal with case 3 the same way as case 1. At least not the
way things currently work. There is an awful lot of 3 going on. If you
don't think so, get a student in your office to explain what a certain
routine is doing and why they chose to implement it the way they did.
(E.g. what does this specific line do? What would happen if we took it
out?) I would bet money, that you will be very disappointed in what is
going on.

If I were to do it all again, I would have to think very carefully
about what cheating is. (I still don't know). You almost have to cut
out all out of class discussions to avoid 3, but that is self
defeating. Once the definition is clear, make sure that all the
students know it, and insure that punishment is severe, and enforced.

Thomas Narten
narten@cs.purdue.EDU or {ihnp4, allegra}!purdue!narten