Why should you read A Philosophy of Software Design?
Otavio Santana
Software Engineer | Software Architect | Speaker | Writer| Book Author | Consultant | Staff Engineer | Mentor | Open Source Committer| Java Champion ?? ??
One of my favorite Brazilian bands, Roupa Nova, once said that the core of beauty is simplicity. Indeed, it goes beyond art and music to software engineering. The philosophy of software design is an essential book to achieve this goal, talking about the opposite: complexity.
The classics of code design, such as Clean Code by Robert Martin, talk about a code that is easy and straightforward to read and maintain. The philosophy of software design goes to the core of the problem.
Complexity is a generic term with an unobstructed and subjective definition. This book brings meaning that I love and use every time: "Complexity is anything related to the structure of a software system that makes it hard to understand and modify the system."
Beyond finding a definition, the book helps to create a measure of it with three symptoms:
- Change amplification: how many places do you need to change a system to create a simple feature??
- Cognitive load: How much does a developer need to know to complete a task? Or imagine that there is an engineer in onboarding; how many days does this person need to complete the first task?
- Unknown unknowns: We live in real life and know that the unpredictable happens more often than we want, and we'll find out when developing an assignment.
To write a good design code is not enough. As a DDD, the book has strategic and tactical programming.?
In tactical programming, we look for the code done and the functionality to work. We know it might work in the short term, but software development is not a 100m race but a marathon.?
Sometimes this programming tactic helps the complexity incrementally, looking for speed instead of quality. I learned a new term in this book, "tactical tornadoâ€, a developer who writes code faster than everyone, but only this developer can read it.
On the other hand, strategic programming shows that code is not enough. Initially, the tactical looks faster, but once code that is hard to maintain has been created, tactical becomes slower than strategic. That is a different approach to thinking about the long-term than speed.
The book cites several success and failure cases of good API design, including some core APIs, such as Java IO. It explains layers, modules, and even more details to avoid complexity in this code.
It is worth reading; I'm rereading this book to review more implementation details and apply what makes sense in my code. A guide for the whole team to create simple code that is easy for everyone to understand and be a part of makes this book a must for software engineering.