Yes, I know it appears that he’s offering it “for free” but appearances are deceptive. Every software company who deals with colleges like this will push their products not merely for free, but with extra donations tagged on. They don’t do it because they’re being altruistic. In fact it’s become a major problem in universities because with funding getting tighter, the pressure to make an economically based decision instead of a teaching based one is enormous. The reason they do this is that it’s a long-term marketing ploy, as explained above. Joel’s just doing it on the cheap. And it’s done in every discipline – Intel funds a clean room here and takes the top two students every year. The top two students here are more often than not actual bona-fide geniuses whose net worth to Intel will far outstrip the cost of the donation Intel made. If the deal can be struck constructively, it can be beneficial, but that’s a rare occurance – and Joel’s idea of a donation just plain isn’t beneficial to anyone but Joel. It is snake oil salesmanship. Heck, it’s not even good snake oil salesmanship at that.

From the article:

“FogBugz would work great for tracking this: if you’re doing a capstone project and need access to FogBugz, please let us know and we’ll be happy to set you up for free. We can also set you up with beta access to kiln, our hosted version of Mercurial, which includes a code review feature.”

I think perhaps you’re basing your view of university education on a poor personal experience. I’m not saying that it’s invalid – there are bad schools out there, just as there are bad companies and bad developers. I’m just saying it’s not valid to tar every school with the brush of the nadir of the field.

As to Joel, firstly I’m doing legwork to find a coherent point in his post to begin with (and the use of open source projects certainly isn’t it, by the way). Every statement he’s made in there, he negates in the last two paragraphs, and that’s before you notice that – as pointed out by commentators here and on reddit and on hackernews – he’s only recently argued against precisely what he’s now supposedly arguing for in this post. Add to that the point that he while he lauds Greg William’s work, he then dumps all over the students actually doing it because they’re, well, students. Rather than accomplished masters. Which seems wrong-headed from the start.

Then after highlighting what he says he thinks is the problem, he shills his own product as a solution. Yes, I know it appears that he’s offering it “for free” but appearances are deceptive. Every software company who deals with colleges like this will push their products not merely for free, but with extra donations tagged on. They don’t do it because they’re being altruistic. In fact it’s become a major problem in universities because with funding getting tighter, the pressure to make an economically based decision instead of a teaching based one is enormous. The reason they do this is that it’s a long-term marketing ploy, as explained above. Joel’s just doing it on the cheap. And it’s done in every discipline – Intel funds a clean room here and takes the top two students every year. The top two students here are more often than not actual bona-fide geniuses whose net worth to Intel will far outstrip the cost of the donation Intel made. If the deal can be struck constructively, it can be beneficial, but that’s a rare occurance – and Joel’s idea of a donation just plain isn’t beneficial to anyone but Joel. It is snake oil salesmanship. Heck, it’s not even good snake oil salesmanship at that.

I finished a university degree 3-4 years ago and to this day, I have not found anything I learnt from it useful during my career in IT.

Joel’s points (although being strongly on the site of software development) are valid in most cases. Not waiting for the last day to finish a project (guilty myself there), team work (absolutely crucial in the real world), self-managing… all valid, fundamental and not slightly surprising qualities that should be taught before starting your career. Its not as if you need to be an expert at it, but it would be nice to include a few projects like that in university.

Also, the point of Joel’s post was that some universities decided to work on open-source projects as their school projects. I cannot think of a better way to teach people about programming while benefiting the rest of the world.
Not only do you get real world programming experience, you learn about developing with other people, version control, probably testing and new ways of managing projects. All this while your hand is being held by your university professor or teaching assistant so it becomes less intimidating. And the best for last, you improve open source projects that everyone can use to benefit themselves, their communities or their businesses.

Also, about the snake oil comment, totally uncalled for. Joel offered giving his software for free to students in the program mentioned to show his support.

And it’s not like there’s no precedent for where we are now – you’re looking at Civil Engineering as a model because it looks like the best one. Well, there’s a reason for that. It is the oldest branch of the profession. It is in effect, stable. It has had time to build up its procedures and practices, to codify its body of knowledge and thrash out a nearly standard syllabus. Software engineering is an order or two (or three) of magnitude younger (depending on what you accept as the origins of civil engineering). Of course it’s not as polished, and certainly you can find poor schools to point at – but you’re cherry picking when you do.

The simple fact is that a Civil Engineering graduate (and I’ve sunk pints with enough of them to know) is as much a neophyte as an Electrical, Mechanical or Computer Engineering graduate. That’s why whole systems exist to provide Continuous Professional Development, it’s why we have the Chartered Engineer title and its equivalents, it’s why there are mentoring programs, it’s why no fresh graduate walking into a job is put in a position where a mistake can cause large-scale damage right away.

You’re expecting a four-year course to produce graduates with the equivalent of ten years work experience and years more of academic study. It’s unreasonable and uninformed to expect that. We produce graduates with the most flexible and wide-ranging skillset we can in order to give the best foundation to build on that we can. But we cannot teach everything. And that’s not a CS/CEng failing – you talk about Civil Engineering as though it was a single job, but it’s an area of industry with hundreds of subcategories and thousands upon thousands of roles; no Civil Engineering graduate has ever been ready to take on all of those roles, and none ever should, it would be a colossal waste of their time to learn how to do ten thousand things when they’ll only ever going to do a handful. So instead, Civil Engineering teaches the fundamentals well and the graduates, with the help of CPD programs, learn more specific skillsets as they go.

This does raise one interesting question though. In Civil Engineering, the Chartered Engineer title (and its equivalents, European Engineer in the EU and Professional Engineer in the US and others elsewhere) are the end product of CPD programs which include courses and mentoring, all of which are actively supported by the companies in this field. Companies budget for training, they actually strive to be recognised as CPD-qualified by the engineering associations and train people to act as mentors within the company, they very actively promote CPD development not just as an optional extra or a reward for their employees, but as a mandatory, socially expected activity for those employees. A civil engineer who isn’t working towards his Chartered Engineer title raises eyebrows.

So where’s the equivalent level of industry support and pressure in the CS realm? As far as I can see (and have seen) in Ireland, there’s next to no recognition of the C.Eng title – and that ties into the ethos we see expressed time and again by practitioners who argue that no formal training is required in order to be a “good developer”. Technically speaking, you probably could find one or two people out of a few hundred million who could build a bridge without formal training as well, but would you cross bridges built by the other few hundred million untrained bridgebuilders?
And within the companies in the industry in Ireland that I’ve come across — and I’ve yet to encounter anyone who’s worked somewhere with a truly different ethos (as opposed to corporate lip service) — training and CPD is something you might reward the best employees with by giving them an extra day’s holidays to go to a training course, and mentoring consists of micromanagement and little else.

All the workload that in Civil Engineering is spread between universities and industry, in Software/Computer Engineering, employers seem to believe needs to be taken on solely by the universities. Which simply will not work.

Now how we fix *that* is a question I’d like to see answered…

> But you seem to think that CS graduates can’t be developers – and you’re wrong. You need to stop thinking of CS graduates as bricklayers and start thinking of them as engineers

CS graduates are NOT engineers. That’s the whole problem. Industry expects them to be engineers. Academia is saying “sure, they’re engineers”. The graduates may be good scientists, they may have extensive competence in computation, but they haven’t the breadth of knowledge _in the field of engineering_ to be engineers (without additional training).

Engineering: “The application of scientific and mathematical principles to practical ends such as the design, manufacture, and operation of efficient and economical structures, machines, processes, and systems.”

Or perhaps the IEEE definition: “Software engineering is the application of a systematic, disciplined, quantifiable approach to development, operation, and maintenance of software; that is, the application of engineering to software”.

The core focus of CS curricula is on theory and the development of theory; the core focus of engineering is on the application of theory in a practical environment.

Contrast the body of knowledge for Civil Engineering (http://www.asce.org/professional/educ/ , your national BOK may be slightly different) against your CS curriculum (looking only at the portions meant to be fulfilled by a bachelor’s degree). Where are the CS modules on risk, project management, and Professional skills (1/3 of the BOK!)? Where is the CS equivalent of materials science, or a study of contemporary issues _in software engineering_ (as opposed to open problems in computer science)?

> The undergraduate course is a foundation as a result of that – it is not the finished article, because there’s no such thing with developers. It’s our responsibility to ensure that foundation is solid, not to produce some cubicle farm drone able to code in whatever industry specific methodology fad is in vogue at the time.

Pick up a textbook on SE (Sommerville’s “Software Engineering” 6th Ed, for example). Does a typical CS undergrad course cover even a quarter of this book? A course that provides a foundation for a software _engineer_ should be covering most of the material in such a textbook (perhaps some only in a forth year of study). A course that trains engineers should be testing for competency in _application_ of this knowledge (application per Bloom’s Taxonomy, as expected in other engineering disciplines). Are you managing to test applied knowledge without concrete cases or tools?

You may be providing an excellent foundation for scientists. Some of those scientists may even pick up engineering principles and become competent developers. But you will still not be training students to be engineers.

It’s taken me a while, but I finally learned that long-term deadlines (or no deadlines at all) just don’t work with professional programmers, either: you need a schedule of regular, frequent deliverables to be productive over the long term. The only reason the real world gets this right where all-student college teams fail is because in the real world there are managers, who can set deadlines, which a team of students who are all peers can’t pull off.

That’s from his final paragraph.

We’re in agreement on how CS graduates should be taught methodologies rather than just one. But you seem to think that CS graduates can’t be developers – and you’re wrong. You need to stop thinking of CS graduates as bricklayers and start thinking of them as engineers, and by that I mean that you have to keep in mind the fact that engineers never stop learning and qualifying throughout their professional lives. The undergraduate course is a foundation as a result of that – it is not the finished article, because there’s no such thing with developers. It’s our responsibility to ensure that foundation is solid, not to produce some cubicle farm drone able to code in whatever industry specific methodology fad is in vogue at the time.

Managers need to find their role in Agile as a servant leader. The era of industrial revolution style management, where folks are treated like they’re on an assembly line, just doesn’t work — definitely not with Agile. Managers should focus on helping their teams by removing obstacles to work, coaching, and actually providing leadership. Remember a manager measures, but a leader inspires.

In a 14 paragraph article, Joel takes the second to last paragraph to suggest a specific methodology (Scrum) and to offer his product (FogBugz) as a tool that can be used for bug tracking and reviews. The other 13 paragraphs are about the problem industry faces in hiring new graduates: they have no practical or conceptual experience with ANY version control, bug tracking, scheduling, etc.

You have chosen to read this as “you need to teach Mercurial and FogBugz because its the stuff I used and sell”. I read it as “you need to teach about this stuff, and if you need an actual tool to work with then I’ll offer my company’s resources”. Yes, he is marketing and yes he stands to gain. No he did NOT say that specifically his suggestions should be used to the exclusion of others.

> As to your specifications for a CS course, you and I will differ there.

I thought it evident that by saying “include a study of development methodology” I was not specifying an entire CS curriculum, so much as indicating some subset of the minimum requirements of a portion of a curriculum that claims to train software developers. If you are not including the aspects I mentioned then you are not providing even skin-deep coverage of the SWEBOK or of software development practice. i.e. you are training scientists not developers, and the course should not be claiming to train developers.

> If Agile isn’t another string to your bow, but the only string, then your college course hasn’t prepared you

Maybe I wasn’t clear (I thought I was) that the concept of “methodology” should be studied along with a number of methodologies as cases; but no specific one advocated. Right now a graduate “software developer” should be able to explain what a software development methodology is, discuss the pros and cons of following a methodology, identify the typical make-up of a methodology, name a couple of common methodologies (e.g. Waterfall, Iterative/Incremental, Agile) and describe the salient features of each, and have the skills & knowledge to select between two methodologies for a given scenario (and defend the selection).

As to the TCD CS course blurb, don’t forget that TCD’s CS course produced the people who went on directly from TCD (without industrial experience) to found Havok, Iona and various companies in the medical field. So it’s accurate, if not particularly expansive (but then, what sales brochure ever gets the chance to answer every question? That’s what the open days are for).

As to your specifications for a CS course, you and I will differ there. I’ve worked in enough places, and done enough hiring interviews (and it doesn’t take that many by the way), to know that your specification list is not fit for purpose for a CS course which has to equip graduates to go for positions in not merely your company, but the tens of thousands of others out there.

For example, everyone here has been talking about Agile methodologies, but not every company uses them or feels they are appropriate. If Agile isn’t another string to your bow, but the only string, then your college course hasn’t prepared you sufficiently.

Pick up a newspaper or phone an employment agent, ask about programming jobs; ask what qualification is expected. The answer is invariably “Computer Science”. Now pick a student who will enter a CS course at the start of next year, ask what (s)he expects to do with the qualification. The answer is invariably “write software” (or some variant thereof).

The TCD CS course page says “If you can see yourself in a leading team of software developers in computer games, internet software or medical technologies or as a researcher developing innovative technology that will change the way we use computers, then Computer science at Trinity may be for you.” CS departments PERSIST in claiming that they are producing graduates that are competent to enter the workforce, but the very clear response from industry is that CS graduates are NOT competent and require a huge amount of on-the-job training. My company hires EE grads in preference to CS for software development because they are more productive in just about all spheres of the development process, and better equipped to understand and adapt to real-world problems.

Any course that claims that its graduates can become “software developers” needs to include a study of development methodology (note: study, not advocate a particular methodology) and to demonstrate competence in applying at least one methodology (it doesn’t matter which one, what matters is the ability to translate the theory into practice). The methodology needs to include requirements gathering, specification, development, and testing _in some form_. It needs to introduce and apply the concepts of source code management during development and testing. It needs to include real-world considerations like debugging, and how you will structure your interface to get enough detail from a support call to debug the problem. A graduate who is unable to walk into a CMMI level 0 shop, recognise the problems, and know how to go about finding solutions, is NOT adequately trained.

Good grief. No wonder students can’t do anything useful when they graduate. You can’t teach them any real software because they’d be “locked in”.

(Yeah, yeah, I know, that isn’t what you meant. I’m supposed to read you charitably to the same degree that you read Spolsky uncharitably because you’re an academic and he’s a businessman. Sheesh.)

Watching my brother who is a math professor, I have an idea how much pressure there is and how much caring goes into your craft. I know you probably worry about making certain that your students are as well rounded and as well prepared as possible.

I’m just saying that it might be important to those students for you to weigh employer points of view (no, not just Joel’s) as heavily as you weigh peer points of view when developing the curriculum. (And I’m not saying you don’t I just didn’t see that on your list at the top).

Secondly, universities have, as I’ve said repeatedly, a duty of care to the student to not follow advice like Joel’s. They have to act in the best interest of the student, not Joel.

Lastly, Joel’s the one looking for something for nothing here. He’s asking that we cripple the careers of CS students so he doesn’t have to do the kind of on-the-job training every other employer takes as read, and that we’d get them all locked into using his products. And why would we do that? What would we get back in return? Well, nothing. It’s a case of Joel wins, everyone else loses.

Good for him my hat!

Joel is also a businessman, he is offering his work to us for free in his blog – we are consuming his product for free and if he makes a mention of his own product then Good For Him. Shame on you, stop being such a something for nothing bunch of people.

I will keep on reading Joel though, he sometimes have really thought provoking ideas.

When I mentioned industrial tools there though, I was more thinking along the lines of not teaching VCS usage by training the students to use some specific product like SourceSafe, as opposed to teaching them the whole range of VCS solutions from RCS on forwards, as well as the strengths and weaknesses of each, and how and where to use them. Or, to put it another way, we teach students to program using C and C++, not with Visual Studio.

We can’t really make participation in open source projects mandatory. If we can’t have some sort of control over whether or not patches are accepted or whatever, we can’t really make a student’s grades dependant on patches being accepted; and if we based it off patch submission, we’d probably swamp some poor project somewhere with a batch of suspiciously similar low-end patches to accompany the two or three genius-level ones we get in each class.

What we can do (and do regularly) is to have projects like building entries to the IEEE micromouse or Robot Sumo or Robocup Soccer tournaments; to have a final year project that runs for several months and has to be above a set standard for complexity (it’s not unknown for these projects to be sufficiently advanced to have academic papers published about them, one was about mine); and to have a research group run by undergraduates, for undergraduate projects (the now sadly defunct SCRG, which produced microkernel OS work, compilers, and dozens of other interesting projects all through the 1980s and 1990s in TCD’s CS Department, and which I really think we ought to be restoring today).

For example, the Introduction to Embedded Systems (CS7004) course’s final labs will be building one on the other to get up to a final project where an ARM7TDMI board will be doing target tracking and interception using a USB missile launcher toy equipped with a webcam. That’s going to require ticket tracking, documentation and VCS usage, and it’s all part of a structured run at the final problem. Engineering and CS all have similar team projects, from bridge building, to building electric carts to carry beverages, to building a 68008-based system from a handful of chips and wire, a wirewrap tool and a lot of swearing at 2am in the lab