A Philosophy of Software Design, 2nd Edition

This book is comprised of short, easy-to-read chapters on what the author believes are proper software design practices, primarily for the C/C++ and Java languages. Most of the design practices are relevant for other languages and methodologies (functional, procedural, etc.) as well.Whether or not you agree with those practices is another question, and based primarily on which coding style camp you fall into. If you're a firm believer in Agile practices, test driven development, self-documenting code, or the latest coding standard fads you will likely take issue with this book. For example, the author prefers 'strategic' software design over 'tactical' design. The former means thinking about where the system is going and writing code that is maintainable and extensible over the long haul, as opposed to the 'tactical' approach of getting a minimal something running as soon as possible. Of course, such advice conflicts with modern practices such as Agile and associated software philosophies such as YAGNI (You Ain't Gonna Need It). If you agree with the author (as I do) and don't care much for some of these 'modern' ideas you'll love this book. On the other hand, if you live and breathe Extreme Programming, code in JavaScript, and believe that any program that takes more than two weeks to write will miss the market window, well, you won't find much to agree with here.To be fair, I have 40 years of experience in writing software for embedded systems, mostly in C/C++. There really wasn't much in this book that I didn't already know and practice. Like the author, I'm a firm believer in code with lots of well-written comments that document WHY (and not what) the code is doing. Like the author, I find test-driven development clumsy and ineffective. Like the author, I believe that simple interfaces and deep implementations are important, and that small function bodies create bloated, overly-complicated programs with a tendency toward "classitis" (the authors term for too many small classes). In other words, the author's biases match mine, and we both write code in software fields where the languages, tools and targets favor methodical, efficient, maintainable, and extensible code bases. I love this book. A developer writing a front-end for a cloud-based app using a framework-based language, where time-to-market is everything, probably won't.I recommend this book highly for software engineers who would like to take a break from the latest coding practice du jour and write well-crafted, easily maintainable code for a change.

This book complements in many ways another essential book for anyone who wants to be an excellent software developer. I really like the focus on abstraction, the separation of interface and implementation, and the importance of simplicity to minimize complexity and improve performance.

I think every person who has written a fair amount of code should read this book. Managers should buy it for their teams. It should be required reading for new team members (it doesn't long to get through - a few hours).It is NOT for beginner programmers in my mind - you will not have written enough code to understand the points being made. I'd say it's perfect for mid-level to advanced programmers. Why for advanced? Because they can quickly get throught it, and challenge some of their own design assumptions and practices. Mid-level programmers will find it a treasure.The title of the book is perfect, because it really is more philosophical and high-level. But that doesn't mean it's abstract nor boring. I find the ideas very applicable and easy to understand. The opening statements are very powerful - what is complexity, the difference kinds of complexity ("cognitive load" is an excellent concept), etc. It ends with a gem - you know your code is complex if you end up spending a lot of time fixing bugs in it. Complexity begets complexity.Don't let the critical reviews stop you from reading this book - so what, it ignores functional programming. Readers can buy books on that and contrast the desgin philosphy. Yes, it's OOP-based, but so what? It's easy to apply these ideas to non-OOP languages or concepts.Some complained about "3 chapters on comments alone". Not true - the three chapters cover different subjects, and provide excellent guidelines for commenting first (designing with your comments - kind of like writing a mini-spec, if you will), what constitutes a useful comment, and how to name variables. I found it very useful.The concept of "deep" versus "shallow" classes is very interesting, even if some of the reviews have criticized it. The author provdes a very nice clue to whether or not code should be broken out - do you have to keep flipping back and forth between the sub-task and the original function? Maybe it shouldn't have been broken out. Deep classes have simple interfaces and accomplish a lot for the caller. Shallow classes, on the other hand, require the caller to know about them, how to call them in order, etc. Good stuff.It's a short read. You'll scarcely find a book that's so short be so valuable.You can get through it in about 3-4 intense, focused sessions.