A Philosophy of Software Design

I read this as part of a software book club. I think it was a good read, I don't think I would necessarily recommend it to experienced devs, but it probably has a lot to offer juniors and people entering software design fresh. The focus of the book is on how you can cut down complexity - something that matters more the more devs you need to work with day to day. It is easy to develop anything as a small team.

I thought it came across as relatively dated, however it is not that old in the grand scheme of software books. Possibly that's just due to the sample code being Java and C.

--

Stuff I did like included the distinction between tactical (get it working fast) and strategic (get it working well) coding - it's something I think we struggle to balance especially when developing in the agile framework.

Designing things twice resonated - I've almost never got the design for anything right the first time, I think there's a challenge for me there to design at a deeper level. Another member of the book club said they often do some prototyping during the design phase which is an approach I may try to emulate.

Finally, and I think my major takeaway, was the focus on deep modules rather than shallow ones. One of my weaknesses as a dev is a tendancy to overengineer shallow modules and end up with leaky abstractions. Ideally we should prefer a deep module with a simple interface that obscures complexity a developer does not need to know or care about. If we add an abstraction layer, it should remove complexity, not add it - again hard to do when conventions and "what if"'s exist.

--

I wasn't prepared for what felt like half the book to be discussing code comments. I think a good point was made that some comments are valuable. There has definitely been a movement in modern development towards self documenting code that should be extremely readable - and therefore that comments are a code smell.

This holds true - don't just repeat the code in comments, or cover poor naming with comments, but well placed high level comments on the use of an interface or business specific concept can be incredibly valuable. I'm going to keep more of an eye out for this in my own work. I strongly disagree with much of the other advice on commenting in this book, and suggest the second half be taken with a pinch of salt.

--

Other bits I didn't think really hit home included advice to avoid exceptions - I think I agree if they're used as flow control, but actually I believe well done exception handling can massively simplify complexity.

There was also a strange take on TDD saying that it focuses on working features rather than good design. I'm not sure that I see that as a bad thing (hand in hand with his other advice to design things twice...) and I'd much rather start with them than have to reverse engineer something to add tests afterwards because it has not been written in a testable fashion (if it was tested at all...).

There are a few programming books that I keep coming back to. "A Philosophy of Software Design" is one of them.

This is a slim volume. Heck, you can read it in one seating if you set your mind to it. It doesn't have a lot of code samples, and the ones it does have are Java or C++. No trendy languages here, thank you very much. What's more, it has the audacity to say TDD and agile are not perfect. It also says code is not self-explanatory most of the time (but it can be simple), and that's why you should write comments. This is probably why it rubs some people the wrong way.

But you know what? This is a good book. Sure, it's opinionated, but what experienced person isn't? The author is honest about it. And unlike some other authors who seem to think they have all the answers, Osterhout starts the book by telling you to use your brain. You're not going to agree with him 100%, and that's OK.

Don't let yourself be put off by reviewers complaining about this or that. It's a short book. You can read it in a weekend. Read it and make up your own mind.

A few thoughts about some of the other reviews:

- Some people claim this is an OK book for a junior developer, but it can't teach them much. This book rewards people who read it carefully;

- Some people don't like that the author spends so much time on comments. That's silly. It's like complaining about someone telling you to think carefully and organise your thoughts when you're solving a problem. Let them bang out code, and read on;

- Some will complain that the author is somewhat critical of TDD and agile. It's OK, let them bang out code, and learn how to think strategically.