Software Phylosophy
This is my review of the book "A Philosophy of Software Design". I will discuss what I found valuable and what I found questionable.
Hi Friends,
Welcome to the 68th issue of the Polymathic Engineer newsletter.
This week, I want to discuss the book 'A Philosophy of Software Design' by John Ousterhout, a Computer Science professor at Stanford University.
I read 'A Philosophy of Software Design' for the first time two years ago and revisited it several times, so I've developed a good understanding of its principles.
Today, I'm excited to share my takeaways with you.
The outline will be as follows:
introduction to the book
what I found more valuable
what I found more questionable
final thoughts
posts that made me think
Introduction to the book
When I first picked up "A Philosophy of Software Design" by John Ousterhout, I was unsure what to expect.
The book looked succinct for the complexity of the topic. But I decided to give it a chance, especially since a great Software Engineer like Curtis Einsmann recommended it.
Before reading this book, my primary reference for software design was Uncle Bob Martin's Clean Code. However, this book is somewhat different from it and sometimes gives contrary suggestions.
The book's main focus is on something often overlooked: simplifying complex ideas and making them repeatable. Many books share great advice that is sometimes hard to apply in other situations.
John Ousterhout took a different approach. He watched teams and students tackle the same problems and learned from their experiences. This way, he found methods that work not just once but can be used repeatedly.
He believes the biggest challenge in software is dealing with complexity. As programs grow, more people join the development, and everything becomes more complicated to manage.
While good tools help, they can only take us so far. The book suggests fighting complexity with good design, like making code clear and organized and avoiding unnecessary complications.
In the next section, I'll explain the ideas I found more valuable and the ones I found more questionable.
What I found more valuable
Here are the concepts and recommendations that I found valuable in the book:
Deep classes and simple interfaces. A class should be like a good toolbox: full of tools (features) but organized so you can find what you need quickly (simple to use). According to this concept, you should make "deep" classes that hide a lot of functionality behind simple interfaces. This not only simplifies the use of the classes but also makes it possible to manage complexity by hiding the details of their implementation. This approach contrasts with the creation of "shallow" classes, which have more straightforward implementations but expose complex interfaces, thereby increasing the cognitive load on developers.
Information Hiding and Information Leakage. APIs should be designed with a level of abstraction that minimizes the exposure of their internal functioning. This approach prevents the so-called "information leakage," ensuring that changes made to a class or module don't affect the other parts using it. This approach helps avoid problems when you need to change how something works but don't want to break the rest of your program.
Designing Things Twice. This advice resonates deeply with my own experiences since I've rarely been able to find the optimal solution to a problem with the first design. You can see different trade-offs and aspects of the problem by exploring multiple design options. This iterative way of designing helps you come up with not only a solution but also the solution that fits the problem the best.
Tactical vs. Strategic Coding. When you use tactical coding, you focus on fixing problems immediately, which can hurt quality and maintainability in the long run. On the other hand, strategic coding focuses on careful planning and design that pays off in the long run by lowering technical debt and making it easier to add on or change things. This second approach should be preferred since it pushes you to think about more than just the quick fix and to invest in quality and long-term maintainability.
The Importance of Good and Simple Naming. Picking the proper names is critical for making your code easier to understand. Good names help explain what you're trying to do, make the code easier to read, and prevent mistakes. Finding a good name also makes you think more deeply about what your code parts are for and how they work, leading to clearer and more concise design.
What I found more questionable
There are a few ideas in the book I wasn't totally on board with:
Exceptions. The book argues that exceptions introduce unnecessary complexity into software systems. While the abuse of exceptions can complicate the control flow, they remain a powerful tool for gracefully handling unexpected conditions. Many languages and frameworks have been designed with exception handling in mind. I favor a balanced approach, where exceptions are used judiciously for exceptional conditions rather than as a regular control flow mechanism.
Code Comments. The book recommends the extensive use of code comments, advocating for comments on every class, class variable, and method. While explaining tricky parts is good, writing too many comments can make the code crowded and hard to read. If we change the code, we must remember to update the comments, too, which can be a lot of extra work. Sometimes, making the code clear and easy to understand is better, so we don't need so many comments.
Test-driven development ( TDD) is a design approach that works by writing tests for your code before you write it. The book thinks this isn't a good idea because it focuses too much on just getting things to work right now instead of thinking about making the code easy to work with in the future. I don't use TDD extensively, but in some situations, it helps you think through your design before diving in, leading to better-organized code.
Conclusion
This book is not about coding in a specific language or using a particular tool. It's about general ideas that help in designing software better.
It's a relatively short read, but each chapter gets straight to the point, offering practical advice that can be used immediately.
Whether you're new to software development or have been in the field for years, I recommend reading it. You will find something in this book for you.
Post that made me think
Every software developer would benefit from improving their sales and marketing skills, but only a few do it. Most of the time, the problem is not that it’s too hard but that they feel uncomfortable doing it. Link
This is a fundamental trade-off to mention about remote work. On the one hand, remote work has given many developers more options and the chance to make more money. It has removed barriers, providing great job opportunities to anyone with a laptop and internet access. On the other hand, it has made software engineering a much more competitive field, especially for people living in rich countries.