When discussing books on software engineering with colleagues, I got the idea of listing the best books I’ve read in the past 15 years. Because it seems useful, but also because that will allow others to tell me which ones I should have read… Let’s start with some technical books. I’ve never had much taste for books on too specific technology subjects, so there’s no ‘J2EE Internals’, or ‘Jini Programming for Dummies’ books here. Not that I never read anything like that, but those were never books that really influenced how I do my job. Looking at this list it seems that I’m not very imaginative, since most of these are very well known classics. Still:
- Applying UML and Patterns - Craig Larman
Larman’s book (though in the first edition, I haven’t read the third edition I’m linking to here) was the book that first really explained Object Orientation to me. I had had courses in OO before that, but I’m pretty sure I didn’t actually understand it before reading this book.
It was also a nice introduction to UML, which I went all meta-meta-model-overboard on for a while before calming down and focusing on code.
There are other books on UML (UML Distilled is a good one), others on Design Patterns (see below), but if you want to learn Object Oriented Design, and get a good introduction to iterative development, UML and Patterns, then this is the book to get.
- Design Patterns - GoF
I think everyone (who is remotely interested in OO) has at least heard about this book by the ‘Gang of Four’. The first approximately 65 pages of the book are a discussion on what patterns are, why they are useful, and how they are sturctured. The rest of the book is a catalogue of patterns.
Reading the patters will give (gave me, at least) a constant ‘Aha-erlebniss’, ranging from ‘So that’s why they did that!', to ‘So that’s the thing I was doing in that project called!’ to (most often:-) ‘Damn! That’s what I should have used there-and-there!'.
Very much recommended for its obvious and continuing relevancy to anyone writing code. I’ve noticed recently that I’ve been forgetting which pattern was which (not enough coding…), so I suppose it’s time to do a little refresher here.
- Refactoring - Martin Fowler
This one has in my mind always been the companion book the the Design Patterns book. It is structured in a similar way, with a part explaining what refactoring is (‘Improving the design of existing code’, as the subtitle proclaims), and then contains a long list of ‘Refactorings’, which are structured in the same way as in the Patterns book: How to apply in Which situations. This book also introduced the concept of ‘code smells’: those places in the code where you know something is wrong, even in the cases where you don’t know what it is that’s wrong. Again very much recommended. The various descriptions of what is wrong why, and how to fix it, are a great learning experience.
- Test Driven Developement: By Example - Kent Beck
Kent Beck, of eXtreme Programming and JUnit fame, goes into deep detail of the TDD XP practice, by showing step-by-step implementations using TDD. He also explains why TDD works so well, that it is not just a way to increase your test-coverage, how it drastically improves design, and how to use it to write your own unit-test framework.
For some nice links to TDD articles and to Becks (and others) screencasts, see my earlier post. If you haven’t tried TDD yourself, give it a try. The results are surprising…
- Clean Code - Robert C. Martin
I haven’t actually read this one yet, but based on reviews, and on the fragments that I did read, it’s another must-read. Which is why it is on my nightstand in the ‘to read’ queue… The ‘Refactoring’ book teaches you a lot of things about improving code, but this one gives often more basic advice on keeping your code clean, readable, understandable en easy to change.
More when I’ve finished reading this one…
One other book that I’m aiming to add to my queue is Michael Feather’s Working Effectively With Legacy Code, which builds on the Refactoring concept, but grounds it in the ugly reality of dealing with legacy systems (defined as code that is not under test). After reading the original article, and recognising the situations he’s talking about, I’m convinced this is a good one to add.
Same is true for the Pragmatic Programmer book. I did read Andy Hunt’s Pragmatic Thinking and Learning book, and thoroughly enjoyed that, so I expect I’ll be reading this one in the coming months as well.
Next time, books related to Lean and Agile development, which have been my main reading material for the past year…