If there is a lecturer in TCD’s CS department that doesn’t know of the problems and issues Joel just raised in his Capstone Projects post, they’re a rare bird indeed. But what Joel hasn’t mentioned — and what those lecturers can tell you because they’ve been debating it for decades, writing papers on it, holding conferences and have published peer-reviewed journals on the topic, as opposed to Joel’s one blog post — are that there are very specific and very good reasons why CS and CEng undergraduate courses don’t get to cover all the industry tools Joel uses.
To give a brief and inexhaustive list:
- Undergraduate courses in CS and CEng are not there to teach industrial tools, but basic principles, ususally ab initio to students just out of secondary school (high school for the US equivalent courses). This has implications:
- Everyone must work solo. You can learn to work in teams later (and certainly there are team projects all through the four years of the CS and CEng courses in TCD) but until you have a grasp of the fundamentals, team projects are worse than useless as they mask the student’s problems with the basics.
- No student is expected to graduate and be able the next day to walk into an industrial role without supervision or training, and no student has ever been expected to do that in Engineering since the first undergraduate course started in TCD in 1841. That’s why we have mentoring, why we have CPD processes, why we have Chartered Engineer (or Professional Engineer) titles granted by postgraduate programmes, it’s why there’s an entire structure there that’s been built up over hundreds of years of experience. Experience that we have paid for with lives in many cases.
- Everyone needs to work on the “interesting 10%” and leave the boilerplate code for later. If we had ten years for an undergrad degree, you can be very sure it’d be covered in detail, but we don’t. And four years only sounds like a long time because you’ve never taught such a course before, and are missing details like the coverage of the entire field of Computer Science being necessary in that four years.
- Undergraduate courses lose their technical currency in something like five years on average (obviously different sectors age at different rates – web programming has a very fast cycle, embedded systems a very slow one). If we started students off on the latest fad language in year one, they’d graduate with an obsolete skill in year four. So instead we’re better serving students by choosing languages which allow the lessons to be taught clearly, or which are at least well-established and unlikly to vanish into obsolesence before they can graduate. That’s why moving basic courses to Erlang or Haskell is probably a poor idea.
- There is no such thing as the agreed best practise in industrial work. Some favour Agile methods, some regard them as toxic. What works in one sector of the industry will leave your business uncompetitive in another. What is a minor issue in one application will actually kill people in other applications. And different industry sectors have different governing legislation. So if Industry, that much-vaunted crucible where only the best practices survive the trial of the invisible hand of the free market, cannot come up with a single code of practice, what exactly would Joel have the universities teach?
- There is a duty of care to the students. There are many evangelicalists out there who promote one form of Agile methodology over another, who promote unit testing, who promote pair programming, who promote Scrum, and so forth. These methodolgies are without doubt all very interesting – but they’re also unproven. If I’d started teaching students in 2005 with whatever the Agile Methodology De Jour was, by the time they graduated in 2009, that methodology had a fairly low probability of being unaltered, let alone the dominant industry methodology. That’s four years of a student’s life, committed to a methodology based solely on the hype its originators could muster together. That’s not just poor teaching and an invitation for justified lawsuits, it’s downright unethical and wrong.
Normally in an article (or blog post in this case) like Joel’s, the last few paragraphs are where traditionally the author is meant to show a solution to an elucidated problem. Joel has highlighted a perceived lack of experience with current industrial tools and practices amongst college students (a faulty perception, but nonetheless). He’s pointed out a root cause (poor time management) which is fair enough – it’s not the sole cause, it’s not even a primary one in most professional evaluations, but it’s a valid contributing factor. So now’s the time for the solution, yes?
But here is where Joel merely says “have the students use my product to track their usage of an unproven methodology”. No indications as to how we would approach the problem of explaining the relevant industrial methods, or how we’d select the specific one we’d teach, or why we should select it, or where it’s best applied and where it’s best avoided, what it’s strengths and weaknesses are, and so forth — just pure old-fashioned, ladies-and-gentlemen-this-product-cures-all-that-ails-ya, snake oil salesmanship.
Our students may indeed have poor time management skills on long timescales (a failing which comp.risks and The Daily WTF and IT Project Failures have been pointing out in industrial programmers for many years now, which to me indicates that industry does not necessarily have much to teach here). At least when Limoncelli wrote Time Management for Systems Administrators he was putting forward a set of skills that had proven to work for him in the field, and he was trying to pass on lessons learnt the hard way. I might not use the book as a college textbook (though I do use it myself personally), but I can at least respect his intent there. But Joels solution isn’t to teach better skills; it’s to sell his software tool to those students. Let’s throw ethics out the window for a moment and say we do just that. Now what? I can sell you the best chisel in all creation Joel, but I can’t make you into Michaelangelo by doing so – I can just take some of your money and give you a tool you don’t know how to use in return.
Frankly, when I teach the CS7004 students how to use VCS and ticket tracking, it won’t be using FogBugz or any other proprietary system, it’ll be using systems they can explore without having to pay fees for, like Mercurial and Trac. And if afterwards they need to go learn Git or Jira, they’ll know the fundamentals and it’ll take them less than a few hours to make the transition. That is what university courses are for, to teach the fundamentals so that the students can pick up specific skills far more rapidly and evaluate tools according to their proposed use. Not to act as a captive and uncynical market for proprietary software tools.
And even after that, in the final paragraph, he admits himself that it won’t work – that you still require a manager to come in and do time management even in industry. That Scrum won’t teach you time management. That the only difference between college students and industrial programmers is that the latter have time management enforced upon them by a manager – in which case, were that the truth (and it’s not a universal truth, and I’ve witnessed that first-hand), then there would be no problem with college students whatsoever.
Gah. Well, perhaps it’s time I should exercise some time management techniques that I should have used years ago — and simply stop reading Joel.
2009-10-27 » Mark Dennehy