The 4 rules of simple design

Simple design: provide fast development pace, low upfront investment, ease to change

What this principle intends is to minimize the cost and maximize the benefits during a software project lifetime. The adoption of this principle is only possible basing the development in refactoring iterations, such as TDD. When we talk about design here, we only talk about the software itself, not product design nor strategic design. User or PO requirements should be treated outside this practice.

These four rules of design were first defined by Kent Beck in the late 90’s, since then, these rules have outlined the fundamental concepts of software design. It is part of the core practices of eXtreme Programming (XP), and in the same way, this practice pursues the quality enhancement and to improve the ability to adapt to the changing needs.

The 4 rules of simple design:

The rules are listed in priority order. Working software first of all, maximize the cohesion and minimize the coupling later.

1.- Pass all the tests
This is the quickest feedback you could get from your system. If you change anything on it, it tells exactly what you broke. That is why is so important to only refactor with passing tests in TDD. Your software should work as it is intended, tests just guarantee that.

2.- Reveals the intention
At a glance, any piece of code should tell what it does, the naming is a key factor here. Software engineering is a social activity, with other humans. So code, should not only be understandable by machines, it should be understandable by other humans. For companies, it is much cheaper to buy a bunch of extra CPUs to run a process, than a couple of developers to help to understand the code. So in most of the cases, there is no need to write cryptic algorithms no matter how much you improve the performance.
Readable code is easy to change, so it really pays off with time.

3.- No duplication
This is not as easy as it looks. It goes a bit beyond than just two blocks of code that are the same. It also applies to structures or concepts related to the business. Two pieces of code may look equal but the nature is completely different, and it does not make sense to merge them, and also you could have to representations of your domain that are implemented differently and they should be merged. That is why these duplications are difficult to spot unless you have an overview of the system and the domain.

4.- Fewest elements
If the other rules were not violated, this last rule, is easy to achieve. You should not be afraid to remove anything that makes the code more readable and understandable, paying extra attention of duplication rule.
This rule fosters evolutionary design over introducing complexity, not needed at the moment, for future changes. As long as changes are unpredictable, with the continuous refactorings, introduce the complexity only in the right moment that is needed.
In the same way, you should clean up all these past design decisions that made sense back then, but not anymore, they are probably already a code smell.


Something to keep in mind
Even though we don’t explicitly need to design anything upfront, it requires some experience in design. Simple does not mean trivial. Brilliant designs will not just emerge because you are following the practices, it comes directly from the development team. Design is an ability that comes with the years.