JavaSchools are not the problem

Post ImageJoel Spolsky is one of the most famous and respected software development commentators, so when he writes an article, it is usually a good idea to take notice. His latest article, The Perils of JavaSchools, was published today and is definitely worth reading. I think Joel makes some good points, but I don’t agree with his entire argument. I don’t think JavaSchools, as Joel describes them, are the problem.

First, Joel mentions that in the old days programmers chose C as their language of choice whereas now they choose Java. His first claim is that Java “is not, generally, a hard enough programming language that it can be used to discriminate between great programmers and mediocre programmers.” He goes on to say that pointers and recursion, two of the most difficult concepts to understand, are no longer taught in so called “weed out” courses.

The lucky kids of JavaSchools are never going to get weird segfaults trying to implement pointer-based hash tables. They’re never going to go stark, raving mad trying to pack things into bits. They’ll never have to get their head around how, in a purely functional program, the value of a variable never changes, and yet, it changes all the time! A paradox!

The first problem with this argument is that pointers are rarely required anymore, and functional programming just isn’t used much. Joel himself identifies both of these facts. He also mentions that to work on an operating system, you pretty much have to understand pointers. That’s the second problem – while that may be the case today, it probably will not always be the case!

I don’t think that a programmer has to learn a really hard language with really hard concepts to be a great programmer. I don’t think it matters much if someone is an expert at recursion and pointers, or if they are an expert at object oriented programming instead.

How is anyone supposed to learn anything if the curriculum has been carefully designed to make everything easier than it already is?

I don’t think that you need to learn the hard way in order to learn anything.

The fact is, things are getting easier than Joel makes them out to be. Managed code is quite a bit easier to write than traditional unmanaged code, but that doesn’t mean it is limited. There is already a research project at Microsoft to build an operating system using managed code (almost entirely). And we’re inching closer and closer to a time when efficient programming is more important than figuring out all of the different ways to solve a problem and then finding the fastest one, or the one that uses the least amount of memory, or separating them on some other heuristic. We’re going to need rapid application development to get things done quickly.

Consider manufacturing. Do you have to know how all of the little pieces work together in a widget in order to make a useful contribution to the team building that widget? What if the widget has wheels, do you need to completely understand the wheel? All of the angles, the way it works, the problems it may encounter? I would argue that the best way to make a useful contribution is to specialize in a particular part of that widget, or even better, the process of building part of the widget. We’d be able to build far more widgets, far more efficiently, if everyone specialized in something than having to understand everything.

Medicine works the same way. All doctors have to learn the same basic stuff, but then they specialize in a particular field. The difference with computing sciences is that we don’t yet know what that “same basic stuff” should be. Is it object oriented programming, or something else? Certainly the conventional wisdom is that you should learn OOP, and thus we teach Java. The “same basic stuff” has become Java, and I have no doubt it will change again in the future.

Second, Joel seems to suggest that the only good programmers are ones with lots and lots of education.

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.

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.

I agree that CS students really should learn to do some actual programming rather than just theorizing about it. I don’t agree though, that a good programmer should be defined by their level of education! I think what needs to happen is a separation of what we currently call “computing scientists.” Those with the PhD’s, and those who like to do the research and try and wrap their heads around weird concepts should be the computer scientists. Those who are trained as good programmers, able to solve problems and actually implement solutions should be computer engineers.

Take my school, for example. We have Computing Sciences and we have Computer Engineering – but the two do not match up to the two types of people I just described. Currently, Computing Sciences encompasses both computer scientists and computer engineers. That needs to change. There should be different curriculum for each.

Joel says:

I’m going back to ones and zeros.

That’s too bad, because Joel is a very smart guy and could probably make a difference in how we move forward. The problem is not with JavaSchools. The problem is that the same school is trying to teach two totally different types of people.

Read: Joel on Software

  • http://www.google.com/search?q=colin colin

    Wooo interesting topic.

    When I was 13, looking at going into year 9, people in my year were offered a 2nd language (Spanish) on top of French, only if they had good marks in Mathematics and English – some theory about capacity for learning, blah blah.

    I guess my point is that I’d like to see some research on (though I tend to follow the hypothesis around) whether good C++ developers can pick up other languages like .NET very easily compared to say a good VB 6.0 or Java developer people going to C++. I’m fairly sure that a win32 developer (C/C++) can go to .NET more easily than the other way round.

    Even if you don’t need to know what going on under the hood, it certainly helps a lot. With MFC, it was not unusual to have to dig out the MFC source code and override it because it was not allowing low-level access to win32 that was necessary to do some tricky stuff, but that’s one reason why the OCX/ActiveX/COM component market flourished: the complexity of win32 could be abstracted away. The .NET framework does a better job of that than MFC did – probably why C++ developers are happy with C#, though .NET 1.0 was missing some big chunks, and the .NET Compact Framework 1.0 was very limited (though much better in 2.0). .NET does have pointers, but they are type safe delegates.

    I wrote a VB.NET Visio plug-in recently and used both iterative and recursive functions to interpret and present a Visio diagram as a piece of e-learning script. The iterative part could have also been recursive, but was cleaner to understand as iterative, whereas the recursive part was a ‘bedmas’ type evaluator for logic expressions so was well suited to using the stack. So I’m saying there’s a lot to knowing algorithms, structures and methodologies – both how to construct them, or when the appropriate .NET framework class should be used. I’ve interviewed many developer candidates who didn’t know how to make their own stack.

    One of the Channel9 videos was of someone demonstrating the kind of algorithm/structure tests that MS asks interviewees to do on a whiteboard.

    Consider who you’d rather have as your car service manager (or dealership owner) – a guy who is great a customer service, or a guy who started off as a mechanic and knows what he’s talking about when you want to know exactly why something is going to cost so much.

    There is certainly an increasing market (and shortage) of good desktop application, web, service & database developers – 4 quite distinct talents of different sizes (reflected in the Microsoft’s new MCP scheme), but if underlying stuff (OS, DirectX, Server products, etc) still needs C++ (and I know the .NET OS project you mention – even SPOT watches are .NETish), along with Microsoft Office and Visual Studio, then I’m sure the future can only look profitable for good C++ developers.

    I can imagine some sci-fi future (or even just a comic strip) where everyone knows just .NET and Windows 3000 runs bug free (ok a sci-fi fantasy) until one day when it falls to its knees and civilisation is back to square one ‘cos all win32 developers are extinct… a bit like Cobol developers approaching W2K.

    Ramble off…

  • http://blog.mastermaq.ca Mack D. Male

    The point is…as we get further and further down the software development path, we have to worry about the basics less and less. Or more correct, we can focus on the new stuff.

    The car service manager analogy doesn’t really work. We don’t have people theorizing about how to change the way we service cars, or about the possibilities. There are no "car service scientists", only "car service engineers".

  • http://www.google.com/search?q=colin colin

    I meant that I’d rather have a car service engineer that knows the underlying mechanics as a service manager, rather than someone that just looks up how-tos and part numbers from a computer without really understanding what does what.

    Scoble’s post about the same thing mentions that Microsoft is finding it hard worldwide to get C++ developers.

    At the more abstract level, there’s some interesting stuff with software factories and domain specific languages going on, but I think it will take a while become it becomes mainstream. I think MS has a DSL preview for VS somewhere.

    This is a weeding test we use for testing developer candidates (and they don’t have to finish, but just be able to talk about what they did, why and what’s left to do, etc):

    In just 1.5 hours using VB.NET, build a functioning scientific calculator that follows regular behaviour with a label display and buttons for 0-9, +, -, *, /, C, CE, =, ( & ). It should follow ‘bedmas’ and parentheses to any level supported by the platform.

    Give it a go :)

    That tests a number of things including analysis, problem solving, algorithmn, data structure.

    For a .NET platform test we do this (providing the service business entity classes and DB without stored procedures):

    Build in 1.5 hours, a multi-tiered corporate holiday submission application. A winform app should allow locating and uploading of file based xml files containing holiday request submissions (previously created by InfoPath) to a service and should also allow the requests to be listed and individually approved. The service is a web service with seperate assemblies for web service, business entities, and business logic (including data access with ADO.NET) and the database should be SQL 2000/2005. A web page (talking to the website) should list the current status of all requests.

    Seem simple? It’s amazing how many people can’t get a tiny part of this done and it’s only a cursory enterprise developer test. Exception handling usually gets missed out.