Slashdot is powered by your submissions, so send in your scoop


Forgot your password?
Trust the World's Fastest VPN with Your Internet Security & Freedom - A Lifetime Subscription of PureVPN at 88% off. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. ×
Education Programming News Technology

Why Computer Science Students Cheat 694

alphadogg writes "Enrollment in undergraduate computer science courses is at an all-time high at colleges nationwide. But this trend that's been hailed by the US tech industry has a dark side: a disproportionate number of students taking these courses are caught cheating. More students are caught cheating in introductory computer science courses than in any other course on campus, thanks to automated tools that professors use to detect unauthorized code reuse, excessive collaboration, and other forbidden ways of completing homework assignments. Computer science professors say their students are not more dishonest than students in other fields; they're just more likely to get caught because software is available to check for plagiarism. 'The truth is that on every campus, a large proportion of the reported cases of academic dishonesty come from introductory computer science courses, and the reason is totally obvious: we use automated tools to detect plagiarism,' explains Professor Ed Lazowska, chair of computer science and engineering at the University of Washington. 'We compare against other student submissions, and we compare against previous student submissions and against code that may be on the Web. These tools flag suspicious cases, which are then manually examined.'"
This discussion has been archived. No new comments can be posted.

Why Computer Science Students Cheat

Comments Filter:
  • interesting (Score:1, Informative)

    by Anonymous Coward on Monday April 19, 2010 @01:56PM (#31900164)

    While I dont promote cheating I do however believe that you should not reinvent the wheel. When I went through school, it was encouraged that we look for examples and code that we could modify or reuse to fit our needs as long as we understood the concepts and could prove we understood it.

  • by keithpreston ( 865880 ) on Monday April 19, 2010 @01:59PM (#31900218)

    This would be flagged but wouldn't pass the manual review. As a former Graduate Teaching Assistant, cheaters are easy to spot because they are LAZY! They turn in the exact same files (same comments with same misspellings) with maybe a different name at the top. The only good way to cheat is to make sure every things is perfectly correct and has no identifying characteristics.

  • by jwinster ( 1620555 ) on Monday April 19, 2010 @02:03PM (#31900312)
    Please mod parent up. I agree wholeheartedly with this comment in that there is a really large barrier to entry in CS. I'm a CS grad, and I remember reading the introductory paragraph to my "Introduction to Programming" book stating that this is not a good book for first time programmers, only people with some experience should use it. Luckily I was able to keep up with the learning curve (despite that being my first time programming as well), but it's choices like that which lead to CS dropout rates of 50-60%, and inevitably, cheating.
  • by IndustrialComplex ( 975015 ) on Monday April 19, 2010 @02:09PM (#31900442)

    I use code libraries and recode old stuff to new uses every day - is that cheating or just efficient coding?

    Most of the professors I had would state that you were allowed to use a set list of libraries. If you wanted to use a different library, it had to be written by you and included in your submission.

    The set list of libraries was quite small, usually something like std.h and not much else (I don't know if that was the library, I haven't written anything in C or much else for 10 years)

  • Re:Why? (Score:5, Informative)

    by Z34107 ( 925136 ) on Monday April 19, 2010 @02:12PM (#31900490)

    It's neither new nor subtle; it's why expertsexchange now hyphenates their URL:

  • by gestalt_n_pepper ( 991155 ) on Monday April 19, 2010 @02:15PM (#31900538)

    It's a matter of logic, not language. isn't the issue. It's now so close to C#, that it might as well *be* that. It's certainly no easier, or harder, for that matter.

    The most useful "programming" course I took, other than algorithms and data structures was symbolic logic. I'll bet that this course would be a fairly accurate predictor of who passes and who fails in programming.

  • by mschuyler ( 197441 ) on Monday April 19, 2010 @02:16PM (#31900560) Homepage Journal

    The many examples here of array declarations or variable initializations are not sufficient to get you pegged as a cheater. But when you get multi-line programs of dozens of lines that are precisely the same, even including comments, THAT will ring alarm bells. I don't think anyone writing a simple 'Hello, world' program that is exactly like mine will get called out. If you turn in a hundred line program full of regression equations to plot the Fry Readability Index in a matrix graph that is precisely like mine? Busted!

  • Re:software sucks (Score:4, Informative)

    by poena.dare ( 306891 ) on Monday April 19, 2010 @02:49PM (#31901134)

    "just because two people use the same algorithm doesn't make one of them a plagiarizer"

    The irony - because of skroooie US patent laws - when two people use the same algorithm it makes one of them a IP infringer!

  • by omglolbah ( 731566 ) on Monday April 19, 2010 @02:52PM (#31901168)


    I fondly remember one problem we had to solve in college....
    It involved some fairly annoying math and most of the task was understanding 3rd year math in an intro course....
    What ended up happening is me writing a class that everyone else copied and used for the math in their assignment.

    Amusingly the teacher didnt punish anyone for this. He found it incredibly clever to just write the framework and "outsource" the math ;)

    Then again... most of our turn-ins were never looked at. We just needed to turn in an empty folder with our name on it to qualify for the final exam. The teachers never bothered actually looking them over. Too much work.... Asshats :-p

  • by drumcat ( 1659893 ) on Monday April 19, 2010 @02:57PM (#31901236)
    No one is saying that almost every major makes "Intro to computing" compulsory now. Why is it that we are surprised? The more you require people that aren't interested, the more they'll cheat. The more widely compulsory you make these courses, the more dumbed-down they are; the kids that are good are going to be lazy on purpose. Why not? Finally, you have tools to check that your History prof doesn't. Three very compelling reasons why there would be more cheating, not even taking into account the ease at which it is done. Yet, when these same kids get out in the real world, we call them EXAMPLES and REPURPOSING, and we tell them to COPY things out of books and sites that are KNOWN TO WORK. In reality, there's not enough cheating going on.
  • by breinera ( 1638993 ) on Monday April 19, 2010 @02:59PM (#31901266)
    As a teacher who used Moss (for a Measure Of Software Similarity), it was dead on. I taught an introductory course for non-CS majors and when MOSS detected something above 90% similarity, it meant cheating was involved. When I questioned the students, they all confessed. I would say about 20% of the class was caught cheating at one point of time or another.
  • by ShadowRangerRIT ( 1301549 ) on Monday April 19, 2010 @04:45PM (#31902676)

    I had a similar experience. Technically, a correct assignment could be done in different ways, but it was a limited enough assignment that I'd be hard pressed to identify cheating on a correct assignment. Fortunately, the two people who decided to cheat not only did it wrong, they did it hilariously wrong. The assignment was to create "bank accounts" based on an input string (c for checking, s for savings, m for money market). Each account created got $400 more than the previous (the initial account got $500). Then you ran each of them through three months of accruing interest (only difference between account types was interest rate), printing the value at the end of each month. The instructions were far more explicit than I'm being; output was provided for enough example inputs so checking your work was trivial. The two cheaters interpreted it in a hilariously incorrect fashion: they statically created exactly three accounts, one of each type, then used the input string to determine which ones would earn interest. So a string of "csm", instead of creating three accounts and running them through three months interest would run each static account through a single month's interest, then terminate. "ccc" meant the checking account ran for three months, and you saw nothing at all for the savings or money market.

    And of course, they were lazy as hell about the cheating. The only difference in the code was variable names, and they weren't even well disguised; rather than changing them, the other submitter just appended to the original name. A variable named "cash" in one submission became "cashMoney" in another.

    Lesson to future cheaters: If you're going to cheat, cheat off someone who isn't a complete moron. In CS1, you can only solve the problem correctly in a few ways; identifying cheating is hard, and you're not likely to get called on it unless your solution is character for character identical. But if you solve it in a uniquely dumb way, you'll get caught, and provide amusement to TAs for quite a while.

  • I TA'ed an intro to CS class that used these error tools, and this was almost 10 years ago. Cheating is a very serious accusation, or at least was taken very seriously by the professor of the class, and several methods were used to ensure there weren't false positives. The first half of assignments were not run through the cheat system, because they were a bit too simplistic and could have caused false positives. The latter half of assignments were all 100+ lines of code.

    The system did several checks, and included positives with and without whitespace. In most cases where we had matches, there was a 100% whitespace match, right down to sloppy indents, trailing whitespace, etc. Clear cut copy and pasting. Smarter students would try to clean up the whitespace, usually by adding extra lines, changing comments, or removing some, but it was usually pretty obvious from the diffs as to where they would miss some and it would blow their cover.

    The system also did code structure tests, and could pretty easily tell if you just renamed some variables and messed around with whitespace. This was a little harder to review, but when you checked their analysis, I agreed with the results.

    All positives were personally reviewed by the professor and TA's, and to be quite honest we were conservative when actually making formal charges against a student- if only a non-critical function (IE the code to load in the list of items in a file in a binary search problem, but NOT the function that actually performs the search) or two seemed to have a direct match, we would warn the students not to share code again and let them off with a warning. I can't recall ever seeing a real false positive. The professor more or less forced you to use vi or emacs on the linux cluster to write your code, so there was no IDE manipulation of the code, and CS students have no sense of coding standards or consistent style, or even reasonably formatted code for the most part, which made cheats even easier to spot.

    We taught source control (RCS) pretty early. We told students to check in early, check in often. We understood that beginning CS students were pretty poor at frequent check-ins, but my professor would often give them the option of trying to prove that they were at least not the mere copiers by providing their RCS logs to view intermediary versions and progress. Often the cheater and the cheated on were pretty obvious. The source of the code usually had a few check-ins well before the deadline by someone with a B or better in the class. The copier, if he had any, was usually a few hours before the deadline and had been a C or worse student.

    The professor wouldn't punish to the full extent that he could unless there was 100% certainty there was cheating going on.

    Personally, I think there is (or at least was at my school) more cheating in CS because it takes a LOT of time to produce relatively little output. A "page" of code could easily take a CS student 4-8 hours to produce fully debugged. When it comes down to deadline time, there is intense pressure, and if someone leaves their files in their home directory undetected, or walks away from their terminal to use the bathroom, the temptation was too great for them, if they couldn't get the code by begging and schmoozing. Some thought they could just use code from previous years, except that we already had a database of previous years assignments (oops).

    The only time we ever had a gray area was in the case where a student claimed that they had no idea how the other student got their code. Even then the professor would generally error on the side of caution, but watch the student like a hawk in the future. It was all pretty obvious, I don't think anyone was unfairly persecuted, ever.

Any sufficiently advanced bug is indistinguishable from a feature. -- Rich Kulawiec