It seems to be that lecturers are only interested in the curriculum and the students are only interested in their results… So inevitably there is a divide… The question really is how to fix it… A change in the mark schemes? Or teaching style? Or do we just throw them in at the deep end.. which is what happened to me… (possibly the best thing to have happened to my programming!)

http://www.sdml.info/collard/oop1/

I quote:

“This blog entry describes what I have been attempting to get around. This is one of the main reasons that I introduced a versioning system for submitting your programs, and why I encourage you to submit multiple changes not just the final result. Good software is iteratively developed, not brain dumped into a file at the last minute.”

I applaude you for caring for your students future.

Your anecdote is kinda ironic to me because the company that I descibed in my first post had outsourced the development of thier software product to an ISV that worked in exactly the fashion that you describe: “hack in the lastest fix/workaround, duct-tape that new feature on and get it out the door”.

The result was a product that was full of bugs and was impossible to maintain because the code was a mess. So, the code was brought back in-house and a new internal team of developers was hired (I was part of that team, our new manager implemented these code reviews). Each bug fix was reviewed by the entire team before it was applied to the codebase. Same for each new feature. We had code style standards, mostly documentation standards. At the minimum every method had to document its semantics and any side-effects. We also had rules against code that had side-effects, had methods that were required to be called sequentially, etc. Basically we had a bunch of rules against various kinds of ‘bad smells’ in code.

Many fixes had to be reimplemented because one team member would realize that the ‘fix’ would cause problems in some other part of the code (there was a lot of global data and classes). Anyway, within a year the team had whipped that code into something solid. Never was anybody forced to reimplement something
just becuase it didn’t ‘look’ like good design. The code either met our requirements for good code and for the assignment or it didn’t.
This team produced high-quality code very efficiently because a) requirements were set up front, and b) code reviews ensured that submissions met the requirements.

I had the dubious joy of “inheriting” a software project outsourced to a ISV run by a University professor who tended to hire his own students. Code comments? Modularization? Documentation? Forget that–it was just “hack in the lastest fix/workaround, duct-tape that new feature on and get it out the door” the whole way through.

I realize that this is a single anecdote, but obviously those programmers picked up those attitudes (as well as a disregard for people skills–but that’s another story) somewhere. In this case, lay the blame right on the PhD’s office doorstep.

Thankfully, I quit that job after five months for a much saner programming team…

This rule eliminates long theological discussions about code style, it avoids rework for dubious reasons, and most importantly it avoids the resentment generated by forcing someone to rework code for no reason other than the fact that it doesn’t satisfy someone’s ambiguous notion ‘goodness’.

If readability is indeed a requirement then you make sure that it is stated as a requirement up front and that you have a code guidelines in place. If maintainability is a requirement then you should make sure that it is stated as a requirement up front and that you have some guidelines in place. If reusability is a requirement then you should make sure that it is stated as a requirement up front and that you have some guidelines in place.

What you describe as ‘University Syndrome’ is no such thing. It is your failure to completely define the requirements for developing a piece of code. There are a million ways to implement a piece of code. If a programmer happens to implement an assignment in one way that doesn’t happen to suit your definition of ‘goodness’ then the problem is that you didn’t define ‘goodness’ up front.