What Makes Good Code? (4/7)
Less is more
So far, we discussed some principles from good code and whenever I was presented to a new principle, I wanted to apply it in every single place that I could, but that is a big mistake. There is another acronym that warns us about that, and it is the KISS principle: Keep It Stupid Simple.
To explain this, I draw this simple figure and it represents the space where we have all solutions in how complex they are in the X-axis and by how correct they are in the Y-axis. Your first attempt to build something will in most cases be in the lowest part of the Y-axis or correctness because uncertainty is part of software engineering: you don’t know what the system may turn into, the requirements can change and takes a lot of iterations until you reach a stable solution that meets all users’ needs. The X-axis represents the complexity of your solution, on the left side is the simplest solution that focuses only on solving the problem, represented by the A node. On the right side, it is the most complex-decoupled-distributed-flexible-and-every-fancy-stuff-that-exists solution represented by the Z node. So, you must choose between A and Z, which solution is the best?
If you choose solution A, the next step is to move to the B solution. That is a more complex solution and more correct because now you have more information about the problem. You can rewrite the part of the code that is working in solution A properly, fix what is not working and add the necessary complexity to reach B solution. You can do the same process until you have reached X solution!
If you choose Z, the next step is to make a simpler solution because the complexity you added to your solution maps to a different problem, so the only option is to throw away a lot of the structure that you have built and do things from scratch again to reach the Y node. And then, you must do another complete rework to reach the X node. It takes much more time and effort.
When it comes to complexity, every problem has a better data structure that fits it, what parts should be decoupled and what should be contained and sometimes it is not obvious what is the right solution. You could compromise performance and code readability using a very flexible approach and it might work for you, but in my experience, you should start simple and increase complexity as needed. Minimalism is an art movement that influenced design, architecture and even a lifestyle. Steve Jobs was a minimalist and his ideas were crucial to build the iOS User Interface, a concept that literally changed the world. It is all about focusing on simplification and on what is most relevant in your life. This idea ties to the KISS principle.
From the first section of this article, the motivation for it was a job interview. The focus of my interview’s answer was that good code is maintainable and I think that is the most important concept that generates all these topics. People get paid a lot of money to maintain legacy code, because few people have the guts and the knowledge to work on it. One of the reasons is that legacy code is hard to maintain, that leads to another important tip: refactor your code whenever you can. If you follow the KISS principle, you may end up with code that works but it is not very readable or decoupled enough. It is always important to criticize your own work and try to improve your code whenever you can, the sooner the better.
One key aspect of refactoring is peer review. When you are coding something you have the mental model of what is happening on the code, but when someone else reads your code, they won’t have this mental model and they will rely on what is written on the code to build this mental model. The easier that is to read your code, the faster they will build this mental model, and this is an important part of making a good code. Another important aspect of peer review is that the other person should use your code or implement part of it, so that the peer will be forced to understand and provide important feedback that might not be detected by glancing at your code.
The next section will discuss the readability, that is one of the most important requirements for maintainable code.
