When I used to take my kids around to see their grandparents, they'd rush outside to play with the dog in the dirt. My mother used to just smile and say, "Dirt is an essential nutrient for toddlers."

No, they mean 'lean-to' code. As in the software equivalent of getting a builder to build you a house and after 12 months finding you've got a lean-to that will hold a few boxes.
I'm sure we've all had to work on systems like that.

A non-trivial programming assignment is difficult to write, and a good, robust marking scheme is even harder. At the university where I work (I'm what Americans would call a TA) we give our first years a supervised programming lab every week. It usually takes two or three semesters to get the bugs out of the task specifications, and that's with the lecturer and two to five TAs working together.

Programming tasks that have never been assigned to students are like software that hasn't been beta-tested: even if the designers and implementors are top-notch, there's still likely to be some unforeseen interaction with the environment and the users.

If cheating is worse in the US, it's unlikely to have anything to do with who does the grading; detecting cheats is really not that hard. It's more likely to be a combination of, firstly, a perceived disconnect between the task and the student's personal goals, and secondly, the general devaluing of intellectual skills that seems to be endemic in Anglophone culture.

I teach an introductory CS/intermediate Java course, and we use pair programming for most of our lab work -- it's not so much about saving marking time as about getting to give students better-quality feedback. We mark all our labs in class, so we get to quiz the students in person and let them tell us the reasons behind their design choices, but that means our marking time is fixed.

So what we do is mark each student on his or her comprehension of the solution, as demonstrated in the marking interview. Weaker students get little benefit from riding on the coattails of stronger students. We do find the odd strong student who's not willing to let his or her partner touch the codebase though. Pairs like this we either counsel or break up.

We also don't let students have the same partner more than three times during one semester, so they get practice at working with programmers of different skill levels.

In my experience, everything gets backed up, just in case. The backups get stored. We reuse bits of code in our next project. The artwork just gets deleted to make space. Eventually, no one left remembers what was on those backup tapes/DVDs/discs, and they get tossed to make room for more backups.

I can think of two games where as far as I can tell, there is no trace we ever spent half a year on them, apart from us occasionally saying, "That would have been so cool if we'd finished it."

In Australia, at any rate, there's no great shortage of people with qualifications in IT. There is however a desperate shortage of people who can actually function in IT jobs.

We've had University-level computer science courses since the seventies or so, like everywhere else I guess. During the dot-com era, loads of institutions started up so-called "information technology" courses, mostly aimed at vocational programmer training. These courses do *not* teach anything about algorithms, because (and I quote an IT lecturer) "they're never going to have to worry about that in the real world". Now fair enough, they probably won't have to worry about algorithmic complexity or do a formal proof of correctness after they leave uni. But these guys aren't learning *anything* about algorithms -- including how to develop or test one.

What most IT graduates have learned how to do is translate algorithms into Java. Someone else has to come up with the algorithms for them and write them up in detailed pseudocode -- and if you've got someone on staff capable of doing that, it's not that much extra effort for them to learn Java syntax. If thirty years of research into learning how to program has told us anything, it's that learning the syntax ain't the hard part. Unless you're learning INTERCAL, in which case all bets are off.

Meanwhile, CS programs that still teach all that stuff are still copping flak because of a general perception among undergrads that it's irrelevant, and that what employers REALLY want is someone who knows the Java libraries backwards. I reckon that's nice and all, but a) that's the sort of think you can pick up from a reference book after you've taken second year Algorithms and Data Structures, and b) what the employers I've spoken to really want from a programmer is someone who, after a reasonable training period, doesn't need to be told how to do everything they have to do.