Understanding the Four Rules of Simple Design

Have you often heard some of your colleague talk about them and wondered what they are talking about.What are these rules? Where do they come from? Why they follow a certain order? . Corey Haines tried to put these into easy to understand and simple terms through his book.

There is no perfect design. A design expresses what an application does at a certain moment in time, but the requirements will change. People will get new insights as time passes and might come to the conclusion that there is a better way.

The intention of simple design is that it will be easy to change, being adaptable to the changing needs, without making everything configurable. This does not mean that we should strive to make everything configurable. Quite the opposite. Rather than planning for change points, we build systems that can change at any point.

Four rules of simple design

1. Tests pass. If you can't verify that your system works, then it doesn't really matter how simple or complex your design is.
2. Expresses intent. One of the most important qualities of a codebase, when it comes time to change, is how quickly you can find the part that should be changed. Variable, method, and class names should describe what they do. This is also refered to as the principle of least astonishment or the element of least surprise.
3. No duplication (DRY). This rule isn't about code duplication; its about knowledge duplication. Instead of looking for code duplication, always ask yourself whether or not the duplication you see is an example of core knowledge in the system.

Every piece of knowledge should have one and only one representation - The Pragmatic Programmer.

4. Small. It is important to look back and make sure that you don't have any extraneous pieces. A system should be no bigger than it needs to be. Always check :-

• Is there any vestigial code that is no longer used?
• Are there any duplicate abstractions?
• Have we over-extracted?