Stochastic Geometry

October 27, 2009

Joel Spolsky, Snake-Oil Salesman

Filed under: Academia,CS7004,General — Mark Dennehy @ 02:18

snakeoil 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.

Advertisements

86 Comments

  1. You’re right, college is supposed to be about fundamentals. But lots of schools aren’t even doing that correctly.

    Yes, not every assignment can be in teams, but having some team projects at all helps. Nothing I’ve ever done in a professional setting (save my startup, for obvious reasons) has been alone.

    Mentioning bugtracking or VCS in some fashion at all would be helpful. Yeah, don’t teach them FogBugz, but at least an explanation of the general concepts and how to use them would be nice.

    Teaching them the inner workings of Scrum might be silly, but some sort of insight into agile vs waterfall vs whatever would certainly be useful.

    There has to be some kind of balance. I don’t think that college should be vocational school, but some level of preparedness would be nice.

    Comment by Steve — October 27, 2009 @ 02:58

    • But all of what you just described was in my undergraduate course over here Steve – and that was sixteen years ago for pete’s sake. It is not a new idea. And yes, it’s not perfect, it’s always evolving – but it’s been that way since 1841 and the day it stops changing, the day we say “yeah, that’s as good as we can get it”, that’s the day the industry dies on its feet even if it doesn’t notice it at first.

      And this is being academically studied in depth – there are whole journals by the IEEE and the ACM on the topic, there are multiple conferences, hundreds of academic papers every year, lots and lots of deep, peer-reviewed thought on the subject has been going on for decades.

      Comment by Mark Dennehy — October 27, 2009 @ 03:04

    • Before I start what has turned into quite a rant, let me say that I am not a Joel fan, but I do agree with at least some elements of his post here.

      Those practical might be in your course, but it’s not in a whole lot of other courses and where it’s done that I know of, it’s not done well. I too had a capstone course that purported to explain version control systems and agile versus waterfall development, but it really only paid lip service to these concepts and very few students came out understanding the benefits of those systems. In fact, I distinctly remember one team that said version control made their project harder because they couldn’t work concurrently on files. That is an utter failure and did more harm than good to impressionable minds. The basic fact is that some practical concepts need to be more than just *taught*, they need to be underlying foundations of an entire curriculum.

      I perfectly understand the argument that teaching towards the practical end can quickly put knowledge out of date, but for some practical skills, it is the WRONG attitude. Science students have to learn lab procedure, many Engineering students have to learn CAD. Computer Science students should learn at least version control, automated testing, and possibly some project automation (build tools). These are things that have been used in industry in some guise or another for decades and they are in no way becoming less relevant or outmoded. I don’t think anyone (even Joel) is arguing that particular instances of these tools have to be used.

      I mean, for the love of God man, no one taught me how to get a C program to dynamically link against a shared object in any of my dozens of courses that used C and C++, let alone how to properly write a unit test or manage a project with version control. I mean, I went to a fairly prestigious private university, and that is a personally embarrassing lack of common practical knowledge. I don’t know what it’s like at the institution you teach at, but elsewhere the willful decision to not devote any focus on practical knowledge is producing students SO useless in any professional capacity that they might almost have been better not attending college just so that they could have spent 4 years learning practical skills from people that they could interact with online. I do value the theoretical knowledge I learned, and I managed to come out on the practical end okay, but only because I read diatribes from people like Joel and learned where my institution was failing me.

      And don’t you even dare knock Haskell. Those are some of the few people in the entirety of computing that are actually going out of their way to cleanly unite theory and practice. While they’re avoiding success at all costs, they’re moving the state of practical computing towards theoretical soundness far more than I can say of any of the pure academics I’ve ever met.

      Now I’m angry, harumph!

      Comment by Danno — October 27, 2009 @ 15:51

  2. I once read an article post written by Joel Spolsky titled ‘The Guerrilla Guide to Interviewing’ which struck me as particularly asinine but I thought that perhaps it was an outlier. Later on I read a few of his blog posts and promptly crossed him off my list. Nowadays, if someone recommends a piece by Spolsky, the first think I think is that maybe I should cross the recommender off my list too.

    Comment by lee — October 27, 2009 @ 03:07

    • Hahaha hilarious. I find most of Joel’s ideas mediocre and not even really “ideas” – more rehashing of what others have done better, as you say. He comes up with occasional gem, but I think he should spend more time fixing the bugz in his buggy software — would lend him more credibility.

      Comment by Adam Fisk — October 27, 2009 @ 03:38

  3. You have a button with your name I can put on my shirt. Really, I do admire you

    Comment by Doug — October 27, 2009 @ 03:27

  4. there is a trend for people like spolsky to try to convert a computer science education to a trade school education. computer science exists because it’s a wonderful academic blend of math and science and it is not a 2 year technical degree (with absolutely no disrepsect toward 2 year degrees). “fogbugz” has nothing whatsoever to do with computer *science* joel (asshole).

    Comment by kevin — October 27, 2009 @ 03:35

  5. The sole purpose of Joel’s advert is to suck people into arguing with it, citing it and advertising it for him as you just did.

    However, I do have one question for you: I am having great success writing commercial parallel programs for technical computing using F# thanks to inlined higher-order functions and the wait-free work-stealing task queues of the TPL. AFAIK, no free software supports this style of programming even though it is already being using in industry. How can you expect to teach it without using proprietary industrial technology when everything open source is already obsolete in this context?

    Comment by Jon Harrop — October 27, 2009 @ 03:41

    • How appropriate that an article railing against snake-oil salesmanship would get a comment trying to sell another snake-oil, namely, F# (or perhaps just some flying frog consulting).

      F# is just a .Net implementation of (Oca)ML. Every idea in F# had its genesis (and working implementation) in academia and open source. To claim that “everything open source is already obsolete” is absurd and reveals either your lack of knowledge, or your lack of honesty. “TPL” is just a library in F#.Net, a particular way of doing concurrency. It is not fundamental. It is unnecessary and immoral to chain students to (usually inferior) commercial products as you suggest.

      And let’s be honest about F#. Whatever cool things you may be doing with F#, the reality is that F# will do little more than enable a small number of Microsoft-centric programmers to claim to be doing “functional” programming just as MFC enabled (much larger numbers of) them to claim to be doing “object-oriented” programming in the 90s.

      Excellent article, Mark.

      Comment by Chris — October 27, 2009 @ 06:46

    • Jon,

      Please take a look at Scala and/or Erlang which both supports inlined higher-functions which are both definitely not obsolete. (Actually Erlang was developed before C++)

      ilan

      Comment by ilan berci — October 27, 2009 @ 13:39

  6. I really think you’re onto something, so I really hate to do this, but I’m commenting to correct your spelling. It’s not “Agile Methodology De Jour”, it’s “Agile Methodology Du Jour.”

    In my opinion the correct answer is to stop reading Joel. Limoncelli’s book is awesome but you don’t need him to tell you that.

    Comment by Giles Bowkett — October 27, 2009 @ 03:51

  7. I stopped reading Joel a while back. When an appreciable amount of his posts started to take on the odor of an advert, it was time to “Put the blog down Sir, and take a step back”.

    That being said, I have to disagree that undergraduate education in computing sciences cannot provide more industry oriented preparation. I’m curious what “web courses” that could’ve been taught 5 years ago have lost their currency in 2009. Javascript, nope, still here. CSS scultping, nope, still here too. HTML crafting (sorry, had to pause there) ennngh, no. Now if you were talking about something like FrontPage, I wouldn’t consider that in the category of something that would be center of a “web course”. Tools, perhaps, but technologies ? What programming language that was widely in use 5 years ago has become utterly useless for a recent grad ? I honestly can’t think of one, and please do tell me, as I’m sure to tell some of my fellow classmates not to bother with them ( I returned to the the university after 19 years in the industry to pursue a Masters degree ).

    I’m not saying that in some software engineering course that Scrum should be THE only agile methodology espoused to the undergrads, I’m saying a survey of them should be covered as an essential requirement of completing their studies. Regardless of how much “supervision” a recent grad might be perceived of needing ( and I’ve seen some who did, and more than a few who needed no such hand-holding ), bestowing them the ( as another commenter put it ) fundamentals, shouldn’t consist of only things like predicate calculus, recursion unrolling, and algorithm analysis. Let’s be honest, the vast majority of CompSci grads aren’t going to go on to graduate programs, and it’s a disservice to NOT more adequately expose them to the realities of how “the industry” works.

    Sorry, but one course in undergrad software engineering, and a senior project alone doth not preparation for working in the industry make.

    I’m sure I’ll get my share of detractors, but articles elsewhere have made the same arguments, or similar. I wish I had the citation. In case someone might remember, there were two gentlemen, well-known professors who’d worked on military-grade software systems.

    Comment by Marcelo Lopez — October 27, 2009 @ 05:15

    • 5 years ago, writing your website in Perl was a totally reasonable decision. Today, most people wouldn’t even think of it in the face of RoR, Django, or even PHP.

      I’m not saying this disproves your post, but I think it should give you pause.

      Comment by Larrik Jaerico — October 27, 2009 @ 15:24

    • Err this is meant for the commenter below: There’s nothing wrong with using Perl for web apps, take a look at Catalyst – http://www.catalystframework.org/.

      Comment by Adam — October 27, 2009 @ 19:01

  8. Joel has some nice ideas on management, but when he ventures outside of that realm and into technical topics, he’s a complete travesty.

    Comment by moron4hire — October 27, 2009 @ 05:21

  9. Well, I think the author has missed the whole point.

    I don’t like Joel either but I think he’s not saying what you think he’s saying.

    The point is academia should be closer to industry.

    I think it’s more related to what do you do CS for? Someone, maybe, someone, is doing CS to be an academic and do research and come up with an algorithm better than disjktra.

    Most of us, really vocational, are there to change the world through technology, building software that makes people lives better.

    And college should be more oriented to doing just that, how do you ship a product that can indeed make a change?

    And I think that in fact most of the teachers(not all) don’t have a single clue how to do that.

    When a wise man points at the moon, the fool looks at the finger.

    Cheers

    Comment by Juancho — October 27, 2009 @ 05:35

    • Right on. Many “schools” (we like to call them “universities”) do not have separate CS and SE curricula, industry has been conditioned to accept that CS degrees indicate training as a developer, and academia is not doing much to make its CS courses more vocationally relevant OR to correct industry’s perception.

      Even worse, from an academic perspective, is the amount of SE research being performed by CS graduates who don’t have a proper background in engineering or management (yes, management skills are a fundamental part of civil, electrical and mechanical engineering and part of the BOK for those professions).

      To put it bluntly, no-one hires a physicist to build a bridge; CS must either be vocationally relevant or limited to academia and places where science (as opposed to engineering) is truly required.

      Comment by Twylite — October 27, 2009 @ 08:46

    • I hate to repeat myself, but the entire post above was based on the idea that our CS courses are close to industry needs. But they’re not precisely what industry needs today. It’s the duty of care again. The university owes it to the student investing four years of their life to not teach them something that a company in industry thinks is highly important today – and may well drop tomorrow. The university is ethically obligated to take a longer-term view, over the career of the student, and prepare them for that as best they can.

      As to the capability of the teachers, I’m not sure where you went to college, but it’s not the case in most colleges that the lecturers don’t have a clue. Certainly in my department we’ve got a large number of lecturers who have not only had lots of experience in industry, but who’ve been successes there. The founders of Havoc lecture here, for example. Yes, there are one or two who haven’t been to industry – but they’re a small minority, not the majority.

      Comment by Mark Dennehy — October 27, 2009 @ 12:15

  10. good post..

    Joel is a over-hyped (over commented) blogger ..most of his ‘ideas’ are untested, unproven dictums questioning the established just for the sake of questioning..

    when i started reading his blog initially, i found it interesting and insightful. Now it seems, he has run out of ideas and posts because the world knows him for his posts..

    an undergrad course is meant to touch upon topics so that students have a general understanding.

    if someone wishes to specialize, one may postgraduate…(not sure how many post graduate courses teach Joel’s tools)

    about time management… my college always .. always starts sessions/semesters on the same day every year… declares results on same dates every year

    Comment by student — October 27, 2009 @ 05:36

  11. And don’t forget how to survive the interminable meetings you will attend as a non-student. I swear that was the worst part of working after school (and that was 20+ years ago!).

    Comment by Doug in Seattle — October 27, 2009 @ 05:41

  12. Dang, I forgot my other complaint about Joel’s recent diatribe–that no CS profs ever worked in the *real* world. That is inconsistent with my upper-division classes. One guy (data structs, I think) used to regale us with his days at GM. Another (my graphics prof) I ran into doing contract work at Mentor Graphics. I think most had worked “in the real world” at more than one occasion.

    Comment by Doug in Seattle — October 27, 2009 @ 05:45

  13. Jon,

    Given a solid background in the functional paradigm, concurrency and parallel algorithms would you have right the tools to learn the F# technical computing work you do?

    Things like revision control software, ‘methodologies’, paradigms (OO, functional, relational) are widespread and long standing parts of our industry. The context of their history, evolution and purpose will students into the science beyond, the reach of evangelists. My undergraduate education failed in this regard, and left me without the context to vanquish the traditional accounting/consulting company bureaucratic process mantra.

    There is an important trade to software development. However skilled trades people are undervalued at present in the anglo world. So social factors prevent us pursuing an approach which acknowledges this, and we need to stick to creating professionals for the good of those educated.

    Comment by artsrc — October 27, 2009 @ 06:03

  14. “….here 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.”

    Did you mean TDD? I might agree that TDD has some problems, but unit testing (or testing in general) is not unproven, it’s a fundamental aspect of CS.

    Comment by George Chatzigeorgiou — October 27, 2009 @ 07:35

    • I was referring to TDD, BDD and DbC and the other variations on the theme. Unit testing is definitely considered a mainstream practice, though not yet a fundamental one (It’s not been around long enough and tested long enough for that).

      Comment by Mark Dennehy — October 27, 2009 @ 12:20

    • So I guess the proven way is to click your way through it? Or if it’s an embedded system the user should start emulating sensor data? That’ll be fun.

      Do you teach students that every time the make a change the should make all the possible clicks?

      Building does not exist without testing. Unit testing is just a consistent and efficient way of testing your application/system/whatever.

      Comment by George Chatzigeorgiou — October 27, 2009 @ 13:00

    • George, just because something isn’t thought of as “fundamental” doesn’t mean that it’s thought to be useless. I wouldn’t teach someone TDD or BDD because I don’t know if they’ll be around in five years, but I would teach unit testing because it will be. It’s just not fundamental the way that C would be, or estimating complexity or other fundamental things. Give it a few years and it probably will be.

      But don’t go asking folks to risk four years of other people’s lives on something you believe. Go back to university and teach what you know – then take on that ethical choice yourself.

      Comment by Mark Dennehy — October 27, 2009 @ 13:13

    • Well, we obviously have a different set of rules. I would teach someone to “always test your code” as I would teach him to “always free resources” . I can’t imagine how saying to students “understanding what a pointer is, is important, but making sure it won’t segfault it’s something you’ll learn later. Just screw everything up now”

      Even if I take “only proven courses should be taught” for granted, then I can only name a few dozen things I learned at university that now are completely useless or obsolete. I agree that universities shouldn’t be jumping on to teaching the new hotness , but this coin has an other side: students learn obsolete stuff just because 20 years ago were proven and the university hasn’t caught up.

      Having said that, I completely agree that Joel went over the line.

      Comment by George Chatzigeorgiou — October 27, 2009 @ 13:35

    • can’t imagine how saying to students “understanding what a pointer is, is important, but making sure it won’t segfault it’s something you’ll learn later. Just screw everything up now”

      Neither can I. However, to carry your analogy back to the unit testing topic, what I’m saying we don’t teach how to use Boost’s pool library or how to use Hoard; but we do teach malloc() and free() and not only that C doesn’t catch an out-of-bounds array access, but also why it doesn’t. Likewise we don’t teach TDD or BDD, but we would teach unit tests and why they’re written and what they’re meant to do and what their strengths and weaknesses would be. Do you see what I mean?

      Comment by Mark Dennehy — October 27, 2009 @ 15:28

  15. *clap clap *
    Reading this post has made my head lighter, has raised my spirits and made the world a better place in general for me. 😀

    Comment by karthik — October 27, 2009 @ 07:37

  16. I appreciate your view, I can understand your frustration, and clearly Joel can step over the line with pimping his software from his bully pulpit.

    But. Joel has a little bit of a right to pimp his software and methods. He’s a pretty smart guy. Every point you made is valid, and sure, quit reading Joel if you want.

    But. I’ve learned things from Joel, thought he was a quack, felt glad for his contribution from the pro programming community, and… still value him.

    I hope he comments on this post. I’d like to hear what he has to say.

    Comment by Daniel Talsky — October 27, 2009 @ 08:05

    • To sell, yes. To advertise, yes (within guidelines we lay down in law for good reason). To pimp, or as in this case, to hawk it as a solution to foist on college courses? No, that’s over an ethical line.

      Besides all of which, along with his right to sell, everyone else has a right to comment…

      Comment by Mark Dennehy — October 27, 2009 @ 12:22

    • Mark, he isn’t *selling* his wares in that article. He’s offering to give them away for free.

      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.”

      Comment by Bryan — November 5, 2009 @ 22:01

    • Bryan, as everyone’s said before, it is a sales pitch. Joel’s not giving his stuff away for free here, he’s looking for product placement for free in a market most companies are paying a lot of money to get into. Altruistic, he’s not!

      Comment by Mark Dennehy — November 6, 2009 @ 22:42

    • Well, except that he *is* giving it away for free. I’ve been using FogBugz hosted for free for over a year now. That doesn’t mean I’m drinking the Joel Kool-Aid. It just means yes, he actually is giving the software away to certain groups of people, students doing capstone projects included.

      Comment by Bryan — November 7, 2009 @ 12:22

    • That isn’t giving it away for free Bryan. It’s just not getting money up front. Like I said above:

      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.

      Comment by Mark Dennehy — November 7, 2009 @ 13:07

  17. “I think that it’s extraordinarily important that we in computer science keep fun in computing. When it started out, it was an awful lot of fun. Of course, the paying customers got shafted every now and then, and after a while we began to take their complaints seriously. We began to feel as if we really were responsible for the successful, error-free perfect use of these machines. I don’t think we are. I think we’re responsible for stretching them, setting them off in new directions, and keeping fun in the house. I hope the field of computer science never loses its sense of fun. Above all, I hope we don’t become missionaries. Don’t feel as if you’re Bible salesmen. The world has too many of those already. What you know about computing other people will learn. Don’t feel as if the key to successful computing is only in your hands. What’s in your hands, I think and hope, is intelligence: the ability to see the machine as more than when you were first led up to it, that you can make it more.”

    Alan J. Perlis (April 1, 1922-February 7, 1990)

    Joel has started a company and earnestly wants to be a bible salesman.Developing a boring ‘project management’ software does not interest all and is in no way doing any good to the development of computer science.Colleges and universities are meant to produce people who could propel the development of this field further.We want our universities to strive for producing next Vint Cerf and not a Joel Spolskey.

    Knowing to use a subversion etc is of lesser importance and teaching how to use such specific software should be left for these ‘fogcreek’ type ‘institutions’ to teach in their internship program.

    Universities should focus on more important things like understanding theory of computation and other time-standing brand neutral fundamentals.

    Writing a GUI is not at all important as per developing ideas are concerned.Its the underlying program logic that gets computed is what of the main importance.
    Developing a GUI is of no -value for a data compression software if you can’t implement the ‘compression’ part.

    All the professors know nothing and Joel knows everything.huh.Why does Joel feel as if the key to successful computing is only in his hands!

    Comment by Anubhav Sinha — October 27, 2009 @ 08:16

  18. As someone who started working professionally before I went back to get my degree I feel I have a different perspective I’d like to share.

    To address your three implications in order:
    “* 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.”…
    -Right. 90% of your work in the real world will be in teams, if not more. The classes I have learned the most in have been classes that focused on hands-on experience with problems too difficult to tackle solo in the time allotted. Have them learn team-work but also require them to apportion the project by component with clear responsibilities and require the use of version control from the beginning. I cannot tell you how frustrating it was to have to train a person that had a bachelors in C.S. who told me “I don’t like version control. I never had to use it in college and I was fine.”.

    “* 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.”…
    -Why not? A student SHOULD be able to walk into an industrial setting and start work without more supervision than the other workers. If they can’t then that’s a failing on their part and the part of the institution. If what they learn in a university is not applicable to the profession, why learn it? I remember one professor early on in my college experience who stated “The waterfall method is the only real design method, all the others are fads.”. I pointed out (as I said, early in my college experience 🙂 that wasn’t how we were actually doing it, and it wasn’t how any of our competitors or partners were doing it either, and was ignored. I have more recently had classes that focused on team work, actual problem solving, and choosing whatever methodology you feel suits the problem – IF you can defend that methodology choice.

    “* 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.”…
    -Fours years is a long time, if not wasted trying to spoon-feed techniques by rote memorization. Teach students ‘how’ to learn, ‘how’ to research a subject, and the basics of how language constructs work rather than the specific syntax of a language. Let them use any language, but require them to defend their choice by listing the trade-offs as they relate to the problem.
    -As for working only on the interesting bits I see several problems with that. First and foremost, if they only work on the interesting bits they do not see how those bits work together except in theory – which means they have not internalized the concepts. Second, much of their work in the field of commercial programming will be writing boilerplate code, or if they are good and in a good shop – code to generate boilerplate code. They need to know how to do that, how to debug systems, etc. As a final thought, why is it I have never seen a course devoted entirely to the art of finding and fixing bugs, probably one of the most fundamentally important aspects of any programmer’s job? Why is it that highly useful computer security courses are optional upper division electives instead of both an advanced upper level version and a freshmen “Always keep in mind the following patterns of potential vulnerabilities in your code, and her’s how to fix them”.?

    =Bill.Barnhill

    Comment by =Bill.Barnhill — October 27, 2009 @ 12:21

    • Bill,
      – They shouldn’t be able to walk into an industrial job unsupervised. They also shouldn’t need more supervision than other workers who are just starting off. But the point was, your 21-year-old CS graduate is not going to start work on monday and be the lead software architect on a medical software product by tuesday. We have moved over to the university model of educating students in the basics, but we have still kept some of the trappings of the apprenticeship model as well (because, in the main, four years is simply not enough to train people properly – which is why engineering in TCD is heading down a road of a five-year course, starting by having most students flow from the undergrad to an MSc course, but eventually it’ll become a five-year course, it’s inevitable).

      It’s not about their technical skill. It’s about judgement, it’s about learning the workplace they’re in (and every one has its own quirks) namely it’s specific practices and procedures, and it’s about their seasoning, for want of a better word.

      – Four years is a long time to a highly-motivated, highly intelligent and curious student with a love for the subject. It is not a long time if you’re taking a wider spread of students (as is mandatory because of the level of industrial demand and the reality that not every developer is a Sergey Brin). It’s even shorter when you consider that you’re taking in ab initio students, and teaching everything from maths to numerical methods and estimation to SQL and database theory, to systems languages and embedded programming, to object-oriented programming, to procedural programming, to functional programming, to compilers, to building a computer from the ground up with a handful of chips, a wire-wrap tool and some wire, and a lot of patience and swearing. There is a lot in those courses and you can’t cherry-pick two genius-IQ-level students every four years and run with just those guys, you have to take anyone who meets the basic math and academic requirements and who expresses an interest. (Which isn’t to say you don’t try to push the genius level students as hard as you can, but they’re two out of hundreds on average every year).

      – The electives tend to be on more focussed things than the mandatory courses. Everyone needs to know how to do recursion; not everyone thinks they need to know SQL or AI methods. There’s simply not enough time to make everything mandatory that we think might be useful. Believe me, we wish there was.

      Comment by Mark Dennehy — October 27, 2009 @ 12:39

  19. Hey have you guys read the post?? Now I think Joel’s last post on multithreading, C++ and duct tape programming was really off the mark and that it sounded like a repost from the nineties. But this ones not so bad.
    He was full of praise for Greg Wilson’s efforts in getting students to contribute to open source projects. Greg Wilson by the is the guy behind software carpentry which is trying to get other scientist to adopt computer science approaches to problem solving.
    Hey what Joel is saying is similar in intentions to projects like Google Summer of Code are trying to achieve for the students!!
    I worked in industry (main for investment banks as I had advanced degree in Econ/Statistics ) before i did my CompSci degree. I found to my surprise that that very few of the professors could actually code or really knew about databases design (RDBMS/ Other), embedded systems, etc. Although they had written books on the subjects! Indeed their source code betrayed all the signs that they were amateurs in not addressing issues like maintainability, bug reduction , performance etc. And this is code they wrote for department/campus systems!! That saying my comp. sic degrees and time in academia were still useful as they helped to broaden by horizons beyond the industrial stuff. Anyone for natural language processing, prolog, neural networks..
    Eventually (believe it or not!!) you may need to use them!!

    Comment by Chrisdev — October 27, 2009 @ 12:37

    • He’s full of praise for Greg – and then he dumps all over the students for not producing masterworks, then blames the colleges for not teaching them how to produce masterworks, then says the problem is that college students don’t do time management and college courses don’t teach it, then says Scrum may fix that (and then hawks his product)… and then follows up by saying actually, every programmer is lousy at time management (so that there’s no real difference between college students and industry programmers) and that in industry, they have to have managers come in and enforce time management on the programmers.

      And you sound like you had a bad experience with your college professors. Mind you, when you noticed that their code wasn’t really maintainable and had performance issues or wierd edge case stuff — were you standing in front of a class of 200 students who were less than six months out of secondary school (or high school in the US) trying to explain recursion for the first time to them at the time?

      Comment by Mark Dennehy — October 27, 2009 @ 12:45

  20. Of course he has to end with the basic need for managers. He’s a manager.

    Comment by Marcus — October 27, 2009 @ 13:03

  21. @Mark

    “They shouldn’t be able to walk into an industrial job unsupervised. They also shouldn’t need more supervision than other workers who are just starting off.”

    Technically, you’re right there. But frankly, having counseled more than a few of the fellow classmates around me who are walking out with just their BS/MSCS into the job world THEY ARE, more and more, being looked at supposed to be able to walk in and hit the ground running without major supervision, even in some of the more junior roles. Sounds ridiculous, but I’ve heard it enough times from the few who’ve found jobs that they’re immediately overwhelmed at how “it really is” out there.

    Comment by Marcelo Lopez — October 27, 2009 @ 14:00

  22. “Never take advice on computer science from a seller of bug-tracking software.”

    Comment by Piccolo Principe — October 27, 2009 @ 14:05

  23. Very well written and insightful post.

    Thank you,

    Kent

    Comment by Kent — October 27, 2009 @ 14:32

  24. I read Joel’s article very differently to you. First of all, and most importantly, I didn’t feel like he was advocating the use of any one tool. In my fourth year soft eng course (by coincidence, at UofT, now Greg Wilson’s school), our prof insisted we use a version control system, but he didn’t care which one. Most of the students had never heard of it, didn’t see the need for it and hated his insistence that we use it, but he was right. We also had to track all our bugs – again, not on any one product, and lots of us used notepad/emacs. But they had to be tracked. And we had to have a software development plan: agile, waterfall, whatever, he didn’t care, but we had to decide and write it down. (You guessed it – students hated that too). When Joel says “this might be a neat opportunity to use Scrum,” I read this just as a suggestion in this spirit – what’s important is that *some* method be decided upon and used.

    This stuff seems to me to be almost as fundamental to being a good software engineer as knowing your complexity classes and algorithms. And CVS is almost as fundamental as C at this point. I think it’s totally legit to insist that they be taught in university.

    Secondly, you ask another commenter: “were you standing in front of a class of 200 students who were less than six months out of secondary school trying to explain recursion for the first time to them at the time?” But the article specifically suggested that this be part of the last year of university, not the first. Personally, I think an introduction to the basics of the tools themselves might be in order even earlier, perhaps by insisting that source code be submitted as part of a git repository. Not because git is important, but because it teaches you to check in changes.

    And as for him hawking Fogbugz – I guess my wetware spam filter just filters that out.

    Comment by Adrian Ludwin — October 27, 2009 @ 14:45

    • CVS is almost as fundamental as C at this point.

      No, it’s not.
      First off, you’ll find a large body of people (myself included) who’ve worked with CVS and been badly bitten by it and who know it’s limitations and think it’s only still about because of the inertia of legacy systems and because there are worse solutions. Basing a course on a non-distributed VCS would be a mistake in my personal opinion.
      Secondly, CVS has nowhere near the level of testing C has, nowhere near the size of a knowledgebase or userbase, and nowhere near the level of importance to a graduate.

      All that said, yes, I think a VCS is a critical industry tool, one that should be taught in university courses, and that’s probably why it is taught there, though usually after things like recursion and control flow and a basic grasp of a language. That’s why I said so elsewhere :

      Yeah, we do actually teach VCS over here. It’s just that we teach the basics, then several if not all the systems in use from RCS through CVS through Mercurial, showing strengths and weaknesses and so forth along the way. That way, if they graduate and walk into a shop using sourcesafe, it takes them a few minutes to learn the minor differences and they’re up and running. What we don’t do is teach one system and churn out graduates who are useless if your company isn’t using the system we trained them for.

      Comment by Mark Dennehy — October 27, 2009 @ 15:34

    • Hi Mark, when it comes to VCS, I think we’re saying almost the same thing. Perhaps comparing CVS to C was an overstretch, but what I’m saying is really important is that students must know what VCS is and have at least a passing knowledge of how to check code in and why that’s important. My school didn’t cover this until 4th year, and I suspect would not have covered it at all except that my one teacher insisted.

      As for distributed versus non-distributed – I don’t have a strong opinion there. I’d be surprised if a reasonable student familiar with non-distributed VCS couldn’t pick up DVCS at a later date, but it’s probably reasonable to teach DVCS in the first place.

      Comment by Adrian Ludwin — October 27, 2009 @ 15:49

    • I think we’re agreeing with each other allright Adrian, and the differences are down to us having experience of different universities.

      As to VCS-v-DVCS, I’d prefer to teach both, or at least that both exist. Like I said, start with RCS and SCCS, move on to CVS, then on to Mercurial and Git and look in each case at what they’re good at, where they’re best used and when they’re going to be a pain in the touche.

      Comment by Mark Dennehy — October 27, 2009 @ 15:56

  25. Maybe I’m too old to comment (my CS degree was 1980).

    As others have stated (maybe far more clearly), I think the university curriculum needs to remain tool/methodolgy agnostic while still teaching the fundamental principles and theory (e.g. students should understand unit-testing, but its not necessary to teach test-driven development per se).

    That being said… During my 4 years, I learned far more while working at the computer center help desk than I learned in any of my courses. First and formost, I learned how to read and debug other people’s code. As part of that process, I also was exposed (at least informally) to collaborative development. Therefore, I can appreciate Joel’s point regarding the need for team projects.

    Comment by Dave Morgereth — October 27, 2009 @ 15:48

  26. Mark, I can’t figure out how to directly apply to your comment, my apologies.

    None of that stuff was in my program. I went to a fairly large school, as well. You must have been lucky. I didn’t see any of those things at all.

    Comment by Steve — October 27, 2009 @ 15:50

    • It sounds like you got the unpleasant end of the stick there Steve 😦

      Comment by Mark Dennehy — October 27, 2009 @ 15:57

  27. I’ve been struggling with this question over the past 3 years myself as I finally went back to school to finish that CS degree I never got.

    I was struck by several things (in most of my classes):
    1) Whether it was required or not we are told to not work together as that is a violation of ethics and we’ll get booted. So, in most of my classes they are no team projects – ever. I would love team projects if not to help me, to be able to pass on some of my industry experience to fellow students. But no, that is forbidden in 85% of my classes.
    2) Agile development, version control, etc., the tools of the trade are either: not taught; are available and learn on your own; available as a higher-level course (that is optional of course); not even mentioned. This still amazes me, that there isn’t some introductory class to working in a team environment. We have a basic C/Unix tools course, which teaches us the basics of getting stuff done in Unix, why not something for pair programming, team-work, project management, etc.?

    I’ve waffled on solutions to this, does it mean we have to have two tracks? One for scientific programmers who just want to continue on and do fun research-y things and another for those of us who just want to code? Or should we intersperse classes like the Unix tools class except for team programming. At what point do you make these required? At what point do you say that in order to take 300-level courses you must have this course before moving on?

    I have a feeling the answer lies somewhere in the middle. I know that I missed a lot of fundamental stuff when I didn’t get my degree, and quite honestly I’m glad I went out into the world and did programming first and came back to learn the underpinnings. I’ve enjoyed my classes so much more because of it, so maybe that’s the answer. Have them take a year of classes and then throw them in the job pool and teach them all the tools they’ll need, then have them come back. They’ll be better for it.

    Comment by Warner Onstine — October 27, 2009 @ 16:06

  28. @Larrik,

    “5 years ago, writing your website in Perl was a totally reasonable decision. Today, most people wouldn’t even think of it in the face of RoR, Django, or even PHP.

    I’m not saying this disproves your post, but I think it should give you pause.”

    It gives me pause when I think of the CEO I recently met is so entrenched with Perl that he DOES do website development in it ( in his word, because he can. Glad I didn’t take that job, Hmm. ). So while it may sound like an unreasonable proposition, and others would certainly be right to say “there’s better tools”. Ahhh, but what was it that led you to make such a veritable statement…pracitcal experience. Which was garnered how ? hands-on experience. So, no, it doesn’t negate anything in my argument.

    What might bake YOUR noodle is that if you think that in 5 years people will say “Django, that’s preposterous, we’d never think of creating a web site with that framework.” What I was not espousing drilling A specific language/framework/methodology to the exclusion of all others, but that MORE exposure to any ( or AS MANY ) should be included. If that means that you have to convince the Uni to drop a couple of humanities from the coursework to better prepare your engineers…..so be it. I’ve seldom heard a good engineer quote Milton accurately anyway.

    Comment by Marcelo Lopez — October 27, 2009 @ 16:19

  29. As a software developer, the only value my university education provides is an extra bullet at the bottom of my resume. 99% of what is relevant to my career was picked up outside of university through self learning.
    The CS professors were way behind the students and taught either overly simplistic concepts, or outdated/irrelevant materials.

    Comment by Jin — October 27, 2009 @ 16:57

  30. ‘Struth! We spoken, sir! Spolsky irritates like a glass shard in my shoe.

    Comment by Charlie — October 27, 2009 @ 17:25

  31. @Charlie: “‘Struth! We spoken, sir! Spolsky irritates like a glass shard in my shoe.”

    Were you just trying to channel Poe or something ?? I know Poe, and you, Sir, are no Poe. 🙂

    Comment by Marcelo Lopez — October 27, 2009 @ 17:51

  32. From a different article from Joel’s website – http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html

    //But what about the CS mission of CS departments? They’re not vocational schools! It shouldn’t be their job to train people to work in industry. That’s for community colleges and government retraining programs for displaced workers, they will tell you. They’re supposed to be giving students the fundamental tools to live their lives, not preparing them for their first weeks on the job. Right?

    Still. CS is proofs (recursion), algorithms (recursion), languages (lambda calculus), operating systems (pointers), compilers (lambda calculus) — and so the bottom line is that a JavaSchool that won’t teach C and won’t teach Scheme is not really teaching computer science, either. As useless as the concept of function currying may be to the real world, it’s obviously a prereq for CS grad school. I can’t understand why the professors on the curriculum committees at CS schools have allowed their programs to be dumbed down to the point where not only can’t they produce working programmers, they can’t even produce CS grad students who might get PhDs and compete for their jobs. Oh wait. Never mind. Maybe I do understand.

    Actually if you go back and research the discussion that took place in academia during the Great Java Shift, you’ll notice that the biggest concern was whether Java was simple enough to use as a teaching language.
    //

    Comment by Someone — October 27, 2009 @ 19:42

  33. One core problem is that people major in Computer Science but then start a career in Software Engineering, which is a different discipline.

    Comment by Matt Waggoner — October 27, 2009 @ 19:49

    • Another core problem is that many universities still don’t have different CS and SE courses, and guidance counselors and industry still believe that CS is the degree required when hiring programmers. This problem is academia’s doing, and they need to fix it.

      Comment by Twylite — October 28, 2009 @ 08:06

  34. While I agree with the jist of the post, I’m unsure why you choose to label Erlang and Haskell (implicitly) as likely to “vanish into obsolesence”. I would have expected almost the opposite conclusion, given your line of argument!

    A common argument against using these languages in a CS education is that they will put students off because they don’t look good on your resume. This has now changed a bit, but may still hold some truth.

    The thing that makes both languages good candidates for teaching is that they expose some ideas very clearly for educational purposes. Erlang shines for message-passing concurrency, and is quickly learned. I first came across it at KTH. After 4 lectures, we completed a lab where we wrote a control loop for a phone switch. This was in 1992, and Erlang was likely used by less than 100 people world-wide, but I was elated! It was a superb illustration of the concepts.

    During the core concurrency class, we studied Concurrent Euclid (now dead), Occam (dead) and Ada (indestructible, but not much alive). This was fine. The same course picked up Erlang later, and I’ve seen from student reviews that this was much appreciated. The same seems to be true in just about all places where Erlang is used in the curriculum. Seeing as it’s on an exponential growth curve, it doesn’t seem to be vanishing into obsolesence soon.

    I haven’t experienced Haskell as a teaching language either as a student or teacher, but I can imagine that it is outstanding for teaching some important concepts in functional programming. Having attended POPL last year, it was obvious that Haskell is THE language of choice for most discerning language theorists, as many of the new language concepts presented at POPL were prototyped in Haskell. It seems like talented undergrads _should_ be exposed to Haskell as early as possible.

    One problem with having Haskell in the core curriculum might be that some programmers do not seem capable of learning how to write non-trivial programs in Haskell. It really forces you to think about abstractions in earnest. Having fought lots of people who are convinced that ‘modeling’ means drawing pictures in UML notation, I think there are some extremely important lessons to learn.

    Not that you need to use Haskell specifically – the old SICP course using LISP goes a long way… but it really made me curious to learn what languages you /do/ use in your teaching?

    Comment by Ulf Wiger — October 27, 2009 @ 20:11

    • I’m not sure they’re likely to vanish into obsolescence Ulf – it’s just that I’m not sure they won’t vanish. Where I’m looking at it from, the contrast is more along the lines of C vs Haskell, rather than of an evaluation of Haskell in isolation. Actually, Haskell is used in a maths course or two from what I remember from talking to people in the maths department a few years back – but for computer engineering, it’s simply not as valuable a skill to know compared to C. From what I’ve heard from those who’ve worked in it, it’s got a large number of things in its favour when considered in isolation.

      Comment by Mark Dennehy — October 27, 2009 @ 20:24

  35. > 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 made a conscious decision to write what worked for me and people near me rather than write a book about the theory of time management and productivity. Before writing the book I did some research and found that people do not tolerate more than a certain amount of theory in self-help books. A little bit is motivational, too much is a turn-off. On the other hand, research finds that geeks tend to be motivated by knowing how the internals of something work. That’s an argument for including more theory. I had to strike a balance.

    I don’t recommend Time Management for System Administrators (TM4SA) as a textbook. It is a self-help book. People will only benefit from a self-help book if they feel they have a problem. The 80% of your class that doesn’t feel they have a problem would hate the professor for making them read it. Oddly enough I had terrible time management skills when I was in college. My low GPA is proof! If only I had TM4SA then! (Go figure out that time paradox!)

    On the other hand, I do promote The Practice of System and Network Administration as a text book. It was written with colleges classes in mind (senior undergraduate and masters programs). As proof, each chapter ends with questions, something one generally finds in text books. The questions are designed to help the student review the material with a few “soul searching” questions mixed in here and there. The latter are excellent for term-paper ideas.

    I would like to respond to some of the things you said:

    > Undergraduate courses in CS and CEng are not there to
    > teach industrial tools, but basic principles”

    I agree… but don’t go too far. The use of industrial tools, when used, should be as a demonstration of the principles being taught, not to gain some kind of certification that they know how to use the tool. Banning such tools would be going too far. We all know there are students that are “visual learners”, “audio learners” and “kinesthetic” learners. Using the tools in a real environment is where the kinesthetic learners will benefit.

    When I took my undergraduate class on software engineering methodology, I felt it was useless because I couldn’t see the point of most of what I was being taught. Most of my programming had been done solo or on a small team. I could not take seriously the problems that were being “fixed” by the software methodologies discussed in our lectures. What would have solved this problem? To put me in an environment where we had a large enough team that things started to break down and we needed GIT, Bugzilla, and Tinderbox.

    However, that was in a day when basic tools like source code control, bug tracking, and automated testing were uncommon. Today’s students get more exposure to those things via exposure to Open Source projects than I got in my entire college career.

    What about the students that aren’t exposed to how open source projects work? My guess is that that is the majority of college students. The superstars get exposure but not the majority.

    Tom

    Comment by Tom Limoncelli — October 27, 2009 @ 20:32

    • Well, right first off the bat Tom, thanks for writing both those books, I’ve found both to be exceptionally useful and Time Management has a permanent place on my nightstand as a result.

      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 🙂

      Comment by Mark Dennehy — October 27, 2009 @ 21:00

  36. I think that this post sucked less than most of his recent production. I agree that the mention to FogBugz is a cheap ad, very like his usual style.

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

    Comment by Javier Rojas Goñi — October 27, 2009 @ 23:35

  37. […] Joel Spolsky, Snake-Oil Salesman If there is a lecturer in TCD’s CS department that doesn’t know of the problems and issues Joel just raised […] […]

    Pingback by Top Posts « WordPress.com — October 28, 2009 @ 01:32

  38. This is an easy one, Joel is an employer and he is talking about the education and experience he would like his future employees to have and basing it on his own experience. He sees a problem that he would like to have fixed, rather than talk about how impossible it is to fix come up with alternatives.

    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.

    Comment by Erin — October 28, 2009 @ 01:46

    • Firstly, Joel is being an employer who doesn’t feel he has a duty of care to the career of his employees if he’s recommending that they be trained using his products and his methodology so they can slot into his company more easily. What about the other hundred or so students in whatever course takes his advice whom he does not hire?

      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!

      Comment by Mark Dennehy — October 28, 2009 @ 01:53

    • Mark, you obviously care a great deal about the students and about the quality of their education.

      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).

      Comment by Erin — October 28, 2009 @ 02:25

    • WTF Mark? Have you not read anything Joel has written about building an environment conducive to development and developers? Drop the strawman BS and admit that Joel was advocating the use of “a bug tracker” and “a VCS” JUST like you are, but offered the services of his company _gratis_ because he has the resources to make such an offer.

      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.

      Comment by Twylite — October 28, 2009 @ 08:53

    • That’s not what he’s talking about Twylite. Perhaps you should read more critically. He’s offering lockin to his product on a badly thought out notion that contradicts large amounts of work into how to teach CS and what to teach on the courses. Nothing more.

      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.

      Comment by Mark Dennehy — October 28, 2009 @ 12:46

    • Hi Mark,

      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).

      Comment by Twylite — October 28, 2009 @ 13:26

    • Twylite, in a 14 paragraph article, Joel spent 12 paragraphs building up a problem. One that doesn’t really exist (and he acknowledges as much in his last paragraph). And if you’d actually read what I wrote, you might have noticed I didn’t latch onto the last two paragraphs, but the first 12, because they were wrong (and rather substantially wrong, because smarter people than you, me or Joel have been working on this problem in large numbers for decades now).

      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.

      Comment by Mark Dennehy — October 28, 2009 @ 13:42

    • Hi Mark,

      > 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.

      Comment by Twylite — October 28, 2009 @ 15:02

    • Twylite, you’re arguing with an engineer about what an engineer is and isn’t.
      And frankly, you’re wrong.

      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…

      Comment by Mark Dennehy — October 28, 2009 @ 15:29

  39. “He’s asking that we cripple the careers of CS students [and] get them all locked into using his products.”

    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.)

    Comment by CB — October 28, 2009 @ 06:17

    • That’s a nice angle CB, but I don’t need you to read layers of meaning into what I’ve written to understand what I’m saying. I just need you to actually read what I’ve written. See the comment above.

      Comment by Mark Dennehy — October 28, 2009 @ 12:49

  40. Developers on a Scrum team do not need a manager to come in and “enforce time management” upon them. If that’s the case then you have a very broken Scrum process. The team should be self-directing and self-organizing. The *team* should be managing their time, let members police one another. You have a daily stand-up so it’s very transparent and clear who’s doing what, who needs help, who’s slacking, etc.

    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.

    Comment by Nicholas — October 28, 2009 @ 13:39

    • You need to tell Joel that Nicholas…

      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.

      Comment by Mark Dennehy — October 28, 2009 @ 13:44

  41. I have to say that I have to disagree with this article and the harshness of it. After finishing reading this article, I went to read Joel’s one and I feel that he has some valid points and none of the criticism in this post are warranted.

    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.

    Comment by Jonathan Levin — October 28, 2009 @ 15:52

    • You’re saying all university courses omit team projects, don’t get interim reports on long-term assignments, don’t take part in external projects and so forth – yet I’ve done those myself in here as an undergrad and still see them being done in here today, 16 years later. I know for a fact they’re done in several other universities. I know for a fact that it’s not just in Ireland that we do this. I know for a fact that all this has been hashed out for decades by people who are teaching in this field, formally, in peer-reviewed journals like the IEEE Transactions on Education.

      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.

      Comment by Mark Dennehy — October 28, 2009 @ 16:15

  42. Snake oil. I never hear before. Salam

    Comment by ashartanjung — October 28, 2009 @ 18:13

  43. […] on Computer Science degrees is pretty wide of the mark – for many of the same reasons cited in this counter-argument. Speaking as someone with no formal Computer Science or Programming education, the most difficult […]

    Pingback by My Continuing Adventures in Technology… » What makes a good developer? — October 28, 2009 @ 18:56

  44. I like the picture! I’ve never seen Joel in a top hat before.

    Comment by Michael Pryor — October 28, 2009 @ 21:35

  45. […] this note, I think Mark Dennehy’s post “Joel Spolsky, Snake-Oil Salesman” is a must follow-up read. The discussion that follows in the comments makes some good […]

    Pingback by OrganizeFISH » Blog Archive » Good Things Happen = Utterly Distracted — October 28, 2009 @ 21:51

  46. […] an arbitrary tool or language that the industry is consistant in its opinion. I read this really great response to his article that echos many of my complaints about this […]

    Pingback by zero-blog » The Fallacy of Industrial Expectation — November 7, 2009 @ 05:57


RSS feed for comments on this post. TrackBack URI

Create a free website or blog at WordPress.com.

%d bloggers like this: