Insightful. Simple. Fundamental. These are some of the words I would use to describe Code Simplicity by Max Kanat-Alexander. It was a short read that took a few days to complete, but I found useful nuggets of wisdom in each chapter. The book is about software development principles surrounding creating systems that are maintainable and efficient. It is a great reminder to not over-engineer solutions to problems that require more time to implement long-term. Likewise, lack of planning and architecting of systems can also be a culprit to creating software that will not last in the long-run.
This was a book I was required to read as a student, and I’m very glad that I had to. I’m not sure I would understand the bigger picture of Software Development Life Cycle (SDLC) and proper practices to make sure teams can maintain codebases with the least amount of effort of implementation. Below are some of the highlights from the book that I felt would be important reminders:
“It is more important to reduce the effort of maintenance than it is to reduce the effort of implementation.”
“The ideal solution—and the only way to guarantee success—is to design your systems such that the effort of maintenance decreases over time, and eventually becomes zero (or as close to it as possible). As long as you can do that, it doesn’t matter how large or small the future value becomes; you don’t have to worry about it.”
“Others believe that they are saving themselves time in the future by doing some extra work now. In some cases that philosophy works, but not when you’re writing code that isn’t needed. Even if that code ends up being needed in the future, you will almost certainly have to spend time redesigning it, so you’re actually wasting time.”
Here, the author, Max Kanat-Alexander, makes a compelling point that if any code is implemented that isn’t actually needed, it is essentially a waste of time due to the fact that it will need to be redesigned at some later stage in the future. What can we learn from such a statement like this? How can practices in software development and design be improved when taking these points into consideration?
Although the book is rather short (only 64 pages long), it was filled with stories, ideas, and instances of where these “Laws of Software Design” are implemented. The only thing I would have liked to see more of in the book is reference to actual data and facts. For a large part of the book, the theories and laws explained were presented in a very story-like way with reference to the author’s professional experience on projects. So, I would not consider this read to be academic in nature, just insight gained from a working professional who has shipped large software projects in over ten years. Again, this review is mainly just a summary of the book, and not an in-depth analysis of each chapter. The author lists these laws below:
1. The purpose of software is to help people.
2. The equation of Software Design: (Here is a detailed blog post explaining this wacky equation- link)
3. The Law of Change – states the longer a program is meant to exist, the more likely any piece of it will have to change.
“It doesn’t say whether a change is absolutely right or wrong; instead, it tells you how to rank your options. Changes that will bring a lot of value and require little effort are “better” than those that will bring little value and require a lot of effort.”
4. The Law of Defect Probability – states that the likelihood of a bug being introduced to the software is directly proportional to the the level of changes that you make to it. The more changes implemented, the higher the chance a defect will pop up.
5. The Law of Simplicity – states that the easier that software is able to be maintained, the more simple its individual pieces of code are structured.
“Many difficult design problems can be solved by simply drawing or writing them out on paper.”
6. The Law of Testing – states that the degree in which you know how your software will execute (predictably or not) is related to how you have initially and accurately tested it.
“In general, if you have some very buggy code that is also hard to read, the first thing you should do is make it more readable. Then you can see more clearly where the bugs are.”
Not to go to deep into theory or philosophy on all this… I would recommend reading the book yourself. It shouldn’t take more than a few days to a week to read it from cover to cover. Then you can base your judgement around whether or not it is useful to you as a software developer. For me, personally, I have seen benefits in approaching projects around some of these laws above, which I can share with you at another time. That being said, I’ll leave you with one of my favorite analogies in the book:
“Some people believe that all systems must eventually be rewritten. This is not true. It is possible to design a system that never needs to be thrown away. A software designer saying “We’ll have to throw the whole thing away someday anyway” would be much like a building architect saying “This skyscraper will fall down someday anyway.” If the skyscraper were poorly designed and not maintained well, then yes, someday it would fall down. But if it were built right to start with and then properly maintained, why would it collapse? It is just as possible to build maintainable software systems as it is to build sound skyscrapers.”