Simon Frankau's book reviews

Joel on Software - Joel Spolsky

This book is not terribly accurately named. I worked out that the Joel of the title was Joel Spolsky, but I failed to guess that the 'on Software' in question was 'on Software Project Management'. Still, if I'd looked a bit harder I might have worked this out, or indeed read a lot more of his website.

So, Joel's famous for his blog, where de discuesses software development, and his take on the process, and this book is basically a 'best of' of several years writing. Joel's fame seems to come from being actually fairly good as a programmers, and as a manager. When he manages, he thinks about what's being done, and what's good, and doesn't just blindly follow a methodolody. Much of his work is based around the idea of getting good people and making them think, rather than following a recipe. Another main idea is to just develop with good business sense - a lot of his work is focussed on shrinkwrap software and isn't applicable to developing in-house apps at large companies, and he admits as such. The critical approach, however, works everywhere.

Joel's opinionated and smug. This isn't a particularly bad thing. His opinions generally make sense, and even if you disagree with what he's saying you might have to think a little. He's smug because he's bright and experienced and his approach has been successful. However, there is a bit of a 'if you do it my way, it'll come out good'. Well, it's not quite that bad. He does give lots of concrete advice on things, but mostly in the sense of 'if you don't do this you'll come a cropper' rather than 'if you do this, it'll turn out ok'.

So his advice on project management his given me some new insights into the kinds of approaches that can be taken, but he's actually surprisingly weak on the technical side. It could be that he knows his stuff but dumbs it down for the web, or it could be that he's actually rather weaker at his technology than at his management. Either way, I don't like the fact that I can spot errors in the bits I know about, since I have no idea about the error rate in the fields I don't know about, and am trying to learn about from the book.

To give you a feel for the errors he's making, here's a few I spotted (by the way, the reason my complaints get more spread out as the book goes along is because the book gets less technical, and more managery, as you read it):

p6: C-style strings are nul-terminated. It's not a null terminator. Pedantry? Yes. Is he wrong anyway? Yes.
p9: He compares
```
char* str="\006Hello!";
```
with
```
char* str="*Hello!";
str[0] = strlen(str)-1; 
```
He says 'Notice in this case you've got a string that is null terminated (the compiler did that) as well as a Pascal string'. Very true. As you have in the first case. And it's less error-prone. Apart from the fact he's written a piece of code that overwrites an element of a string constant. Nice. And you can get the length at compile-time using sizeof to reduce the overhead. Oh, and who on earth uses octal? When complaining about subtle screw-ups, make sure you at least understand subtle screw-ups.
p11: Joel recommends allocating space in powers of two. This can actually be a pretty unpleasant size for an allocator to deal with, since it often wants to bung a bit of metadata with each block. But programmers keep wanting powers of two, so I expect the allocator designers just end up with more unpleasant designs to cope with the fact. Joel also talks about doubling a buffer's size each time it needs to grow. My old boss, Matt Morris, pointed out this is a bad idea, since you can never fit the new allocation into the space left behind by all the previous allocations.
p13: 'As every compiler-writer knows, lexing and parsing are the slowest part of compiling.' Bit of a blanket statement, that. And it kind of ignores the fact that if you're doing decent optimisation that can be a very expensive step.
p42: Joel disagrees with Postel's quote about being 'liberal in what you accept and conservative in what you send'. I think it is a useful principle, but you have to be a whiney liberal. Accept malformed data in situations where it's a possibility and you can't do much about the other end - since otherwise you just can't work - but make sure your program complains appropriately. Carrying on with warnings means a) no sudden catastrophe b) the possibility of it being fixed in the future.
p161: 'Often, engineering majors will just assume that everyone knows what Bates Theorem is or what Peano's Axioms are'. Why exactly aeronautical engineers might use axiomatic number theory, I don't know. Why they can't spell 'Bayes Theorem' is also not clear.
p165: Joel recommends telling interviewees who have written correct code that their code is buggy, to see how they react. He also recommends challenging them on something that seems very plausible. Playing silly games where your behaviour is indistinguishable from someone who is thick is not a feature I look for in my interviewers. I'd probably look elsewhere for a job.
p166: Joel disrecommends puzzle-style questions because people can learn the answers, and if they don't get the insight that tells you nothing. He misses the fact that all the questions he's using are pretty standard nowadays and can be learnt, and that a decent puzzle style question will allow you to see a candidate's thought processes.
p341: Mobile phones don't have GPS. They have position information based on the cell they're in, but it's not GPS. Don't call it GPS if it isn't. Thanks.

Posted 2006-09-23.

Full index