On Plagiarism

I wandered down to my department’s study room the other day. You’d think I’d spend more time down there as it’s kitted out with two new 24” iMacs, but as the university neglected to install any software on them there isn’t much point. The department has a vague idea that Macs promote “creative” and “multimedia” activities purely by some form of electrical osmosis. One doesn’t need to physically use the computers in order to receive any benefit; one just needs to be in the same vicinity. As a result, the Macs sit in a corner, unloved and unused, like two £2,000 tributes to the monolith in 2001.

I usually only go in there to retrieve assessed work that is handed back, and very rarely at that, as work is usually handed back weeks or months later than it should have been. On this particular day, I was trying to retrieve a printout of a Linux kernel module I’d written that extended netfilter to do unfortunate things to unexpecting network packets. I’d been given my grade already, but was interested to see if the lecturer had spotted any of the glaring bugs in the code (judging by the grade I got, he hadn’t).

There is a large pigeonhole rack intended for storing work in the corner of the room opposite the Macs, but much like the Macs, this too is unused. Most of the work is tossed onto the table that the pigeonholes stand on, meaning all of the assessed work from all of the department’s classes is jumbled together in a large heap. Finding anything in the study room is just cause for a celebratory beer in the pub on the way home.

After about half an hour of rooting through this mess, I eventually came across some of my work. However, I’d already picked up a copy of this months previously, and had got a substantially better grade for it. On closer inspection, this version had neither my ID number nor my name on it, but it did have a raft of new and exciting bugs, hardcoded Windows disk names (I’ve used OSX and Linux exclusively for this course) and somebody else’s name at the top.

My imitator achieved two impressive feats with this piece of work. Firstly, he managed to screw the program up so badly that his version scored 70% less than mine. Secondly, he got hold of an electronic copy of something I’d written. The first achievement will probably guarantee him a job as an enterprise software developer, but the second feat is more worrying. I know that he used a digital copy of my code rather than a hard copy, because my trademark wordy comments were preserved intact. No-one would want to retype all of that junk. So how did he get hold of a digital copy? The code was stored in two places - the SVN repository on my Mac Mini, to which access can only be gained via an SSH tunnel, and my user area on the department’s network. To get into the Mac, he’d need to know the Mac’s public IP address, my SSH username and password, the location of the repositories in the Mac filesystem, and my SVN password. To get into my user area, he’d either need my username and password, or enough beer to get one of the admins drunk enough to give him root access. Neither scenario seems very likely.

Anyway, I showed the original and the copy to various people, who are apparently going to look into it.

I never did get my netfilter module back.


Small Packages

Several of the chaps on my course are in a similar situation to myself - they are competent IT professionals with a number of years of commercial experience who have decided, for various reasons, to go back to university. This creates interesting problems in a lot of the classes. With few exceptions, the lecturers have no professional experience and come at problems from a purely academic viewpoint, which can cause them to commit terrible blunders.

A good example of this was an astonishing “WTF?” moment when a database lecturer asked some students with commercial experience if they created views as an abstraction layer over a database before they started developing new functionality. He suggested that this could avoid disrupting a live application’s service, which would naturally occur if developers are slowly altering a database’s structure. Good idea if you are in the insane habit of developing on production databases. Bad idea unless you want to get fired on the spot.

These blunders do not sit well with the sensibilities of the experienced students, and some of the more vocal members of the class are not afraid to make their feelings known. Anyhoo, one student regularly pulled up one of the programming lecturers on problems with his code or methodologies. After a particularly fraught debate about XML, DTDs and the Java XML APIs, we got onto the topic of team names for the final group project.

“What’s your team name?” asked the lecturer.
“Big Things Come In Small Packages,” replied the student.
“Oh,” said the lecturer, with a glint in his eye. “Small packages.”