Book Review: A Philosophy of Software Design
I learned about A Philosophy of Software Design by John Ousterhout from a blogpost by Gergely Orosz. His review of it piqued my interest and I decided to read it in the near future. I didn't regret that decision.
I liked the author's approach on looking at the software architecture (or design as he refers to it in the book) through the lens of complexity. I've worked on my share of long-lived software projects with large development teams and growing complexity of the code base was always one of the biggest challenges in daily development. The author does a good job of identifying the symptoms of complexity which make our job harder and dedicates a large part of the book to practices which can help us fight the complexity as time goes on.
Although I was already familiar with most if not all the practices presented, it's nice to see them listed with a succinct explanation of how they can affect software complexity. I liked the most the discussion on how to modularize the software to hide specific complexities from the rest of the code, including the importance of naming and interface documentation.
I was somewhat surprised how much of the book the author dedicated to comments. Since I'm not a big fan of comments in the code, I approached that part of the book with even more skepticism. Despite that, I must admit that I agree with a lot of the author's views. In part, because he also considers interface documentation (which is typically used for generating reference documentation and for tooltip contents in modern IDEs and text editors) to be comments. But also because he emphasizes that the comments should only state what isn't obvious from the code by explaining the reasoning behind the code and not the code itself. While I haven't changed my general opinion about comments, I'm certain that I'll be more thoughtful about them after reading the book.
With all the focus on the comments, I find it even more glaring how briefly the tests were mentioned in the book along with other recent software development trends (as the author call them) like agile development, design patterns and object-oriented paradigm. Although tests are presented as a very useful tool in continuous improvement of the software architecture because of the safety net they provide, their role in documenting the behavior of modules is completely omitted.
Even if that's not completely obvious from my review so far, I can strongly recommend the book to any software developer, no matter his level of experience. Junior developers will learn about techniques that will help them do their job better. Senior developers will probably already know about most of these techniques but will have a great opportunity to consider their importance as they are reminded about them while reading the book. They might even decide to try something different from what they are used to and see how it works out.
The book is available on Amazon as both a physical book and an e-book.
