Why do the 4 rules of SIMPLE design have that order?
Simplicity is the ultimate sophistication. [Leonardo Da Vinci]
Today the topic is simplicity: let’s deep dive into the 4 elements of simple design; also referred to as “rules”, these 4 elements came from the mind of Kent Beck while he was developing the concepts of Extreme Programming.
The 4 rules are:
- Pass its tests
- Minimize duplication
- Maximize clarity
- Has fewer elements
It’s important to explicit that the order is not random, rather it expresses a priority: for example, passing tests is more important than minimizing duplication.
Now, the question is: does this order make sense? Let’s try to think about it together!
The first rule: pass the tests
Kent Beck is telling us that we should first make sure that the code passes its tests.
Passing tests is not trivial, in fact, it hides some concepts that follow from it: first, it means making sure we understand the behavior we actually need to achieve, referring to effective collaboration and conversations with the key people in our business. Also, it implies that we need to make sure we represent this behavior through automated tests that express the need and the result we want to achieve.
Bonus point: writing the tests before the code, following TDD, allows us to do a much easier matching between the expected behavior and the tests themselves.
The second rule: minimize duplication
Duplication is a clear enough concept and I don’t think it is necessary to go into it, obviously, we always want to follow the DRY concept. In this definition, however, there is a keyword: minimize. Not delete or remove but minimize.
There are several reasons why this word is important: the most obvious reference is to the “Rule of Three”, the principle that we want to wait for duplication to occur at least three times before attacking it because this allows us to minimize the possibility of error in the creation of the resulting abstraction. We can, however, side with another deduction: minimizing duplication also means accepting that we may not be able to remove it completely, and that’s okay. If at that moment, in the context we are in, duplication is not a problem, we can accept to keep it, for the moment. For example, if the portion of code is very simple or if we are not yet sure of the correct abstraction to build.
The third rule: be as clear as possible
What does it mean to be clear in code? Good names and obvious code that doesn’t take anything for granted, for sure. But it also means correct abstractions because if they were wrong, it would certainly be difficult to understand a code that represents the business it serves with any distortions or inaccuracies. This motivation is enough, in my opinion, to justify why rules 2 and 3 make sense in this order of priority, but they can also be seen side-by-side.
The fourth rule: use fewer elements possible
This rule explicitly reminds us that we don’t write code as an exercise in style or pure passion, we do it to serve a purpose of a company acting within a certain business. What does this mean?
It means that we want to have the simplest code possible because our goal is not to prove how good and beautiful we are as developers but to have a codebase that is easily maintainable and readable.
So if you can achieve the same behavior with less code, do it!
Remove abstractions that turn out to be too complex, remove a Pattern that turns out to be too much of a solution, simplify, simplify, simplify.
Simplicity is the ultimate sophistication.
