Wednesday 8 August 2007
High And Low
Yesterday I visited Otago University and gave a guest lecture in a software deveopment class there, titled "Developing Firefox". This was a revised version of my "Firefox For CS Researchers" talk, with most of the "future Web developments" and "how this relates to CS research" stuff ripped out and replaced with greater discussion of our development tools, processes and issues. As it turned out I had way too much material for the time available so I also ended up leaving out the discussion of security issues, but that's OK for this version of the talk. I took some interesting questions and talked to some students after the talk for a while.
It's becoming clear that NZ universities steer students towards "safe languages and frameworks" used by IT and Web front/backends, and away from the sort of low-level systems programming required for infrastructure projects such as Gecko. That's understandable --- high-level is where the majority of jobs are, and I'm glad the industry has matured so people no longer write bespoke apps in C and C++ --- but it's also sad, because I think low-level stuff is more interesting in many ways, and tends to have more leverage in its ability to change the world. There is actually a great need worldwide for good low-level engineering and if we have a reservoir of talent here, jobs will flow here too. We don't have to just be another consumer of platforms produced elsewhere. Maybe one NZ university should focus on this while the others feed the IT shops.
(By 'low level' here I don't mean "assembler" or "C" --- I mean low in the software stack: infrastructure and frameworks that provide APIs and languages that other developers build on. For performance, footprint and other reasons this layer is more likely to be written in lower-level languages. I'm well aware of various efforts to write "systems code" in "high-level" languages, and I'm willing to discuss them with the proponents of those languages in comments :-).)
For our recruiting this means the interesting applicants are people who have either done some particular project that required systems programming (sometimes at university, e.g. a Masters thesis), or have just done some on the side for a hobby project. At Otago I exhorted students to consider contributing to suitable open source projects to get this kind of experience. I proposed that such experience opens many interesting career paths, some involving open source projects, but many others as well.
Tomorrow I'm visiting Waikato University to give both the "Developing Firefox" and "Firefox For CS Researchers" talks. It'll be interesting to see how things compare.
Comments
You're right, it would be a really useful thing to add in to a Software Engineering programme.
(I'm Engineering rather than Comp Sci - that probably makes a bit of a difference.)
I shall talk to my colleagues :)
- Colin
I don't want to simply advocate "teach more!" That doesn't work. I would advocate that some students should practise lower-level skills and should *not* be taught IT-oriented subjects like, say, databases.
The three undergraduate "programming" programmes I'm aware of at UofA are Computer Science, Software Engineering, and Computer Systems Engineering.
The Computer Systems Engineers do lots of hardware, microcontrollers, network protocols, but are weaker at programming. The Software Engineers study development methods, project planning, and a bit of design, and I'm sure you're familiar with the Computer Science programme, it hasn't changed all that much since we went through it, although it's possibly more "industry" oriented, (where "industry" = "programmer farms").
I do think Universities need to be changing their focus a bit, they really do seem to be trying their best to become vocational schools that churn out mediocre Java/C# application programmers.
Because, sadly, that's what the students think they want to do :(
- Colin
Part of the problem is that many of the potentially good 'systems' courses instead are comprised of two separate components:
Part A: 'General knowledge quiz' approach to architecture / networks / ..., where one reads a textbook, works through a few contrived examples, and then answers shallow questions in an exam:
Tomasulo's algorithm is a register scoreboarding algorithm (T/F): ___
Part B: 'Pseudo-programming question': simulate a small component of a cache hierarchy / network stack / disk scheduler by filling in 4 missing functions in a Java program.
Glue these two bits together, and congratulate yourself that you've now got a well-rounded systems course covering theory and practice!
Part of the problem is that the students don't learn enough programming in lower level courses to do anything interesting. Also a problem is that many of these courses (networks, os, architecture, compilers) wind up on critical paths for non-specialists and become courses that mediocre or distracted students still have to receive more or less automatic passes for fear of generating inter-departmental strife.
I disagree about not teaching databases though. Almost every project I've ever worked on has used a database, and even firefox is hooked up to one now. Sure, you can learn it on your own but I could say that about half the classes I took as an undergrad.
I probably would have axed formal language theory, a completely redundant statistics class, and the technology ethics class we had to take from the curriculum in favor of some of the more systems level programming and designing APIs, but I'm sure others would think those are less important.
Unfortunately that class is usually one of the more brutal ones, and one thing I *don't* want to import from the US is the massive workload imposed on undergrads at the top universities. That's why I wouldn't propose adding any new classes without also proposing a class it should replace :-).
For me an ideal software engineering course would have many electives in the final year, with the student able to choose three or four from a range of options. networking, distributed, operating systems, user interfaces, agile development, large team development, tools, scientific computing, databases, etc.
Smaller specialized classes are a lot more fun to teach, the students learn a lot more, and you get a much broader range of graduates.
Unfortunately given the current funding models, electives cost a lot. Two classes of 20 students costs almost twice as much to run as one class of 40, but brings the same income into the university.
And software development (as opposed to IT) really doesn't pull in the numbers any more. Most people seem to come in wanting a solid job translating pseudocode into C#. And given their current funding models, the universities take in anyone they can find and shove them all into the same classes.
- Colin