Posted by Nicole Bekkers on 15-9-2016
You might have heard a colleague talk about them at a certain point and wondered what they were talking about. What are these rules? Where do they come from? Why is there an ordering?
This blog post will offer some explanation and insight.
A Bit of History
In the 1990’s Kent Beck first described the rules in his book “Extreme Programming Explained” after it was already discussed on Ward Cunninham’s Wiki. Many other people shared their experiences, including Joe Rainsberger and Ron Jeffries, and refer to them as Kent Beck’s Rules. In 2014 Corey Haines published the book “Understanding the 4 Rules of Simple Design” where he uses examples to explore and explain the rules from experiences from thousands of Code Retreats. This brought new life to Kent’s rules.
The Rules
The rules (well, more like guidelines, but they are referred as rules, so I will do the same in this blog post) outline some fundamental concepts around software design. In the book “Understanding the 4 Rules of Simple Design” Corey Haines describes the rules in the following order:
- Tests pass
- Expresses intend
- No duplication (DRY)
- Small
That sounds simple enough, but what does that really mean? Why in this order?
Tests pass
If you can’t prove that your system works and does what it is required to do then it doesn’t really matter if your design is simple or complex. It will also be harder to maintain and bugs tend to creep in undetected.
Expresses intent
When you look at a piece of code it should immediately tell you what it does and it shouldn’t surprise you. 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.
No duplication (DRY)
The application shouldn’t contain any knowledge duplication, also known as “Don’t Repeat Yourself” (DRY). This doesn’t mean code duplication in the literal sense. Two loops might look very similar but their intention can be very different. It’s about knowledge duplication, duplication of concepts. No duplication of knowledge and what it represents in the domain and making sure those are isolated in one place.
Small
The application shouldn’t have pieces that you don’t need. Remove any dead code, resist the urge to design for the future things you are not sure of you need. Does the application contain parts that seemed a good idea at the time, but was never fulfilled? Time to revise that.
Sometimes it’s hard to see similarities in knowledge when being focused on the details. For this reason it’s good to occasionally take a step back and evaluate the result.
Ordering of the rules
In Kent Beck’s book rule #2 and #3 are switched and there has been some debate about it. J.B. Rainsberger offers the explanation that it doesn’t really matter. When revealing intent, duplication in your application will become clearer and when duplication is reduced it will reveal its intent better.
Putting the rules into practise it will be a dance between the rules many times over.
Simple Design
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. Rather than planning for points in the future where the application will likely change, we can build software that can easily change at any point, by applying simple design principles.
This also means that there is more than one design that works, depending on the situation at a certain time. Comparing thoughts and ideas can yield insight into techniques to improve the code. It might be called “simple design” but it’s not always simple to put into practise. It takes effort, multiple iterations and new insights to improve it bit by bit.
What does this mean for me or my project?
I cannot tell you exactly what it means, this depends entirely on the project, its domain and context. The outcome can be different each time! It helps to have discussions with members of your team and visualize the design in any way you prefer. Go through the code together and try to explain what it does and refactor it along the way.
These rules focus mainly on a class level design, but are not limited to classes or Object-Oriented languages. That’s the beauty (and power) of these rules!
When and where do I start?
You can always start now, but applying the rules needs practise and so it can be scary to just start at any moment in your project. Having a safe environment to practise, exploring the rules and other techniques can help you get started. A Code Retreat will cover the basics of the rules and a means to practise. Check here to see if there is one in your area. If you live in the Netherlands you can visit this website to see when the next free workshop is.
References
Want to know more? Check out these references!
- In the book Understanding the 4 Rules of Simple Design Corey Haines describes his experiences and lessons learned with the rules from thousands of Code Retreats.
- Extreme Programming Explained by Kent Beck
- Martin Fowler on Beck’s Design Rules
- Ron Jeffries on Emergent Design including the rules
- J.B. Rainsberger’s description and battle over the ordering of the rules
- Ward Cunningham’s Wiki