dove@fortune.UUCP (Michael Dove) (09/18/85)
Where I went to school, editing output was not as bad a problem as some others I have seen. We had a submission system so that when you were done with the program, you would submit it to this submission program which would then compile and run your program with the standard data set, and then store away the program and output for printout by the TA's. There were indeed ways around this, but it solved the problem of editing output. The program you submitted did produce the results that were stored, so your program had to produce the correct results. You could always dress your program up to look liked it worked and produce the correct results. But that was usually more work than the original assignment. The big problem was more of code copying. People would trace through the class directories for people who either accidently or purposly left permissions to their directories and files so the world could read them. So you have 20-30 people who would snag a copy of it, spend 30 minutes doing global substitutions of variable names, etc, change the comments, and turn them in. It is real hard for an instructor to notice this so most people got away with it. Many other bugs in unix allow people to read a file even if it is unreadable by the world, so it was a large problem. The only problem these people had to worry about was if the person they got this copy from had a good program originally. I have never know of anyone who has ever caught, but there were oogles of people doing it. It is also one of those things that is hard to stop. The question arises, who has the original code? -- /******************************************\ |* *| |* Michael Dove *| |* Fortune Systems Corporation *| |* {ihnp4, ucbvax!dual}!fortune!dove *| |* *| \******************************************/
brian@ut-sally.UUCP (Brian H. Powell) (09/21/85)
> The big problem was more of code copying. People would trace through > the class directories for people who either accidently or purposly > left permissions to their directories and files so the world could > read them. So you have 20-30 people who would snag a copy of it, spend > 30 minutes doing global substitutions of variable names, etc, change > the comments, and turn them in. ======= > It is real hard for an instructor to > notice this so most people got away with it. ======= > |* Michael Dove *| > |* Fortune Systems Corporation *| > |* {ihnp4, ucbvax!dual}!fortune!dove *| I disagree with the part I set apart in "=======". It's not hard if the grader is paying attention while grading. I generally had 40-60 programs to grade at a time. Especially if the changes to the student's programs are as simple as you state. I remember the flow of the code, not the identifier names. Even rearranging subroutines into a different order isn't hard to catch. (Though with our Cyber line-editor, moving around subroutines in a file was almost good enough for a Ph.D. Thesis, so we didn't see that much.) I guess it all comes down to whether you're skimming the code or studying it. I grade using the latter. You can tell a lot more about how much work the student did by studying the code than by studying the output. Brian H. Powell UUCP: {ihnp4,seismo,ctvax}!ut-sally!brian ARPA: brian@sally.UTEXAS.EDU U.S. Mail: Southwestern Bell P.O. Box 5899 345-0932 Austin, TX 78763-5899 AT&T (512) 345-0932
andrew@grkermi.UUCP (Andrew W. Rogers) (09/23/85)
In article <5560@fortune.UUCP> dove@fortune.UUCP (Michael Dove) writes: >Where I went to school, editing output was not as bad a problem as some >others I have seen... I graded intro FOOTRAN assignments in the early 70's. Back in the Card Age, editing output was obviously an impossibility... but one clever student wrote a program to fake a compile/load/run job (even logging the spurious job on the operator's console)! He scheduled the FOOTRAN compiler and loader directly from his program (instead of via JCL), sent the listing and load map to a scratch tape, wrote some dummy output to avert suspicion, faked the JCL for a new job (both to the line printer and console), copied the tape back to the printer (doctoring the date/time along the way), and appended the "correct" results (part of his data). >The big problem was more of code copying. People would trace through >the class directories for people who either accidentally or purposely >left permissions to their directories and files so the world could >read them. So you have 20-30 people who would snag a copy of it, spend >30 minutes doing global substitutions of variable names, etc, change >the comments, and turn them in. It is real hard for an instructor to >notice this so most people got away with it... I encountered the same thing back in the Card Age! Occasionally some jerk would be dumb enough to rip off someone else's deck and resubmit it under his own name; more often, though, I saw the Card Age equivalent of what you describe above: someone would steal/"borrow" someone else's deck (or listing) and rip off the algorithm, change the variable names and line numbers (speaking of archaic concepts), repunch it, and submit it as his/her own. The very earliest assignments could basically only be done one way with the statements covered at that point, so this was hard to detect; as the assignments became longer and more complex, it became more obvious. There was a long series of articles (either in CACM or the SIGPLAN Notices) about various automated mechanisms to detect programs that might possibly be collusions or ripoffs; however, if an instructor can write such software, there's probably a student who can write something to disguise a "borrowed" program! (Probably harder than writing the assignment in the first place, but who can deny the hack value?) >The only problem these people had to worry about was if the person they >got this copy from had a good program originally. I admit that two programs which generated the same erroneous output would probably be scrutinized more closely than any two correct ones... but that only means that the ripoff artist would have to test the stolen program first, and try another if it was wrong! (A clever instructor, of course, could deliberately put a program with a *very* subtle bug in a publicly- readable directory owned by a fictitious student, and then test all submitted programs with data designed to trigger the bug! Those that failed would be subject to closer scrutiny, since not every program with the bug would necessarily be a ripoff.) >I have never known of anyone who has ever been caught, but there were oodles >of people doing it. It is also one of those things that is hard to >stop. The question arises, who has the original code? On occasion, two suspiciously similar - sometimes identical - assignments were handed in... but there was nothing I could do to distinguish the original author from the plagiarist or to prove collusion. (Exception: when three members of the same frat turned in exactly the same assignment, I split the credit between them.) Usually I would write a polite note on both assignments, saying "Person A: Person B has handed in an identical assignment", and vice-versa, giving photocopies of the assignments to the instructor, and leaving up to the plagiaree (?) to report the plagiarizer to the discipline committee. So far the discussion has centered on students editing output and stealing programs from others *in the same class*. What about recycling programs from previous classes? A lot of the assignments - particularly in the intro level courses - didn't change for years at a time, and it wasn't especially hard to find someone who still had listings or even (gag) decks. While an instructor/TA/grader may be able to detect two identical programs in the same batch, s/he certainly won't remember having seen a program the previous semester! (The obvious solution is to assign different programs each time the course is offered, but some instructors are concerned that the course might thus be easier one term than another.) How long will it be before the term paper ghostwriting (excuse me, "academic research") services turn into "custom software" houses? When will some enterprising soul publish the answers (including sources in listing and floppy disk form) to all the questions in a widely-used intro CS text - as a "study aid", of course, with some totally unconvincing disclaimer added? Andrew W. Rogers
jerry@uwmcsd1.UUCP (Jerry Lieberthal) (09/25/85)
> > The big problem was more of code copying. People would trace through > > the class directories for people who either accidently or purposly > > left permissions to their directories and files so the world could > ======= > > It is real hard for an instructor to > > notice this so most people got away with it. > ======= > > I guess it all comes down to whether you're skimming the code or studying > it. I grade using the latter. You can tell a lot more about how much work > the student did by studying the code than by studying the output. > > > Brian H. Powell I agree with Brian's statement. I also used the method of studying the code, and also paying attention (somewhat scant, tho') to the output. I usually did not have a problem telling what was original, and what was not. There were usually about 40 - 60 submissions during a grading spell. Also, I had the fortunate aspect of using a machine so difficult for student work (and was able to disguise a lot of the job control) that they didn't have time to try and figure out how to rip off other's work. The machine we are *still* using for some work is a Sperry 1100. The hardware may be reasonable, but the software lacks greatly.... -- ------------------------------------------------ - jerry University of Wisconsin-Milwaukee Computing Services Division {ihnp4, uwvax, uwmacc}!uwmcsd1!jerry uwmcsd1!jerry@wisc-rsch.ARPA
oleg@birtch.UUCP (Oleg Kiselev x258) (09/27/85)
> ======= > > It is real hard for an instructor to > > notice this so most people got away with it. > ======= > > |* Michael Dove *| > > |* Fortune Systems Corporation *| > > |* {ihnp4, ucbvax!dual}!fortune!dove *| I think several professors teaching lower division Computer Science classes at UCLA had used formatter/parser programs that would replace identifyers in Pascal programs with arbitrary names and formatted them in a uniform way ( a la cb(1)). That type of manipulation would reveal most of the sloppy and un-careful source stealing.