When I first saw Bladerunner, it seemed terribly derivative. This seems to me to be the fate of things so heavily copied that it becomes difficult to see how original they were at the time. So it is for this book.
A bit of context. This is an old book on managing programmers. As in, when I brought it in, someone in our team said 'I read that twenty years ago'. It's a second edition, so it's been a bit updated, but overall it does show you how little has changed in the world of software development.
Basically, the content of this book is the kind of stuff Spolsky goes on about (he's a great fan of it). The fundamental idea is that managing a programming team is about managing people, and the technical stuff should be pretty good at sorting itself out. As far as this cat-herding exercise goes, it's fairly good.
Generally, the advice is fairly no-brainer, to the degree that anyone with non-trivial experience might skim the book and ask 'And what does this teach me?' As usual, however, the insight and experience in the details make it worth reading, even if you know the outline. It's also good to have a written-down, well-rehearsed explanation of things like 'why slavishly following a methodology is bad'.
The only thing that still might be viewed as controversial is the railing against open-plan. Yes, it'd be good to give programmers their own offices, but not at e.g. an investment bank, especially if you need to be available for support. What can we do? Most of the team end up with headphones. I guess we've lost that war... On the other hand, looking back to the new Cambridge Computer Laboratory, I have a suspicion a copy of this book was handed to the architect, because it follows all the advice, and it was a great work environment.
Overall, it really is pretty thoughtful, and does overturn preconceptions from time to time. It's not a long book, and is no longer startling, but it's worth reading.
Posted 2012-02-12.