A Philosophy of Software Design by John Ousterhout – review
A Philosophy of Software Design by John Ousterhout is a great book. Period. I would say that it is a great additional to reading Clean Code. Clean code in my opinion is dry and very… strict ? Not much room to fiddle around with rules set by Uncle Bob the Guardian of the Clean Code. John Ousterhout provides us with a more kind and flexible approach without strict, dry rules to follow. Since the book was wrote by a professor at Stanford that had classes it might get a bit technical when John goes through the different code sets but it does print a better picture of the whole problem. You can feel how the blocks were made, what was the downfall, and it is usuall because not thinking ahead, just not enough ahead 🙂
This is written around one week after finishing the book.
First and foremost
A Philosophy of Software Design is about how to use Your common sense and stick with it.
Unfortunetly Your common sense can be oblitared by a code review from someone…. that looks a bit differently at that code 🙂 and have different habits.
A Philosophy of Software Design or Clean Code ?
Both. As i started to dislike CC because of strict rules and people blindly following them just 'because’, Phisolophy made me a more flexible person towards code, core reviews, design and everything. The book has rules not only about coding but life in general. You can take out a lot from the book, if You want to.
Highly recommend the book after reading clean code or getting over CC. It is a much more flexible approach and easier that stiff rules. Of course everything should be always taken with a grain of salt and use of common sense. Book in general treats about complexity and how to avoid it. The best design and user / developer experience is when they do not need to think or ask questions. Everything is simple, obvious and by default behaves like one would expect.
One of my favorite quotes from the book
„Complexity is more apparent to readers than writers. If You write a piece of code and it seems simple to You, but other people think it is complex, then it is complex.”- „Sometimes an approach that requires more lines of code is actually simpler, because it reduces cognitive load.”
- „Information hiding can often be improved by making a class slightly larger.”
- „Comments should describe things that aren`t obvious from the code.” – cc made us think that comments make for bad code and failures… i always hated that.
- „Developers should be able to understand the abstraction provided by a module without reading any code other then its externally visible declarations.”
A Philosophy of Software Design bulletpoints and main ideas
1. Complexity is the main problem in software design: Managing and reducing complexity is crucial for creating maintainable software. Three main issues caused by complexity: change amplification, cognitive load, and unknown unknowns.
2. Two main sources of complexity: dependencies and obscurity. Dependencies make it hard to understand and modify code, while obscurity hides important information.
3. „Deep modules” with simple interfaces that hide complex implementations, reducing cognitive load.
4. Strategic & Tactical Programming: Tactical programming (quick fixes) and strategic programming (long-term design). Strategic programming focuses on reducing complexity over time. Critique of Agile: Agile methodologies are encouraging tactical coding over strategic thinking, advocating for a focus on abstractions rather than just features.
5. But on the other hand iterative software design is good, where decisions are revisited and refined over time, rather than decided one-time upfront.
6. Developers should allocate 10-20% of their time to strategic design to improve long-term outcomes that wshoul be beneficial 99% of time. Encapsulating complexity through modular design allows developers to work on parts of a system without needing to understand its entirety.
7. Encourages thoughtful commenting and documentation practices, focusing on clarity rather than excessive comments. Any standard is better then none. Naming Conventions: Choosing meaningful names is crucial; if naming is difficult, it may indicate underlying complexity in the code where a comment might help.
8. Reccommendation of code reviews to identify and address complexity issues, ecourage design principles are applied.
9. Done not optimize prematurely, suggesting a balanced approach to performance and simplicity.Usually simple approach is always more performant.
10. Encourages a philosophical approach to software design, where developers constantly think about and refine their design practices to manage complexity effectively.
11. Red flags can look like :
Shallow modules, classes, objects
Information leakage
Temporal decomposition
Overexposure
Pass-through methods
Repetition
Special generic mixture
Cojoined methods
Vague names
Nonobvious code and functions
12. Define errors out of existence for simplification.
13. Comment should describe non obvious things or make a nice highlight of the code
14. Put the most important things in the center, hide anything else ( especially the implementation ).
15. Remember that You (in general) write the code to make someone else understand it as easily as possible. Including You in one year.
and more ….
The other part that runs in the books is to think when You write cause when You say something is good cause a,b, or c it really can suffer from x,y and z.
A bit of a nudge on CC , if a small class is good then more small classes is better ? 🙂
Recommendation
Yes !
Nothing new in general, we all 'know it’ but we tend to 'forget’ it.
A Philosophy of Software Design is for You to get it, read it, dwell on it. Wil make You a better developer, engineer and productive in general 🙂 You will also appreciate other people approach to things and understand that we are NOT the same. Different is not BAD as much of software engineers think, they belive only one best way there is to do things, and of course there is their way because….. < input reasons here >.
Be more kind and discuss, not correct.
Cheers.
