The 4 rules of simple design according to Kent Beck

Discover the notion of simple design and how it is applied in IT with the 4 rules of simple design according to Kent Beck.

Simple design is a very important concept in programming. He is at the origin of several design patterns and practices whose objective is to simplify our source codes and their understanding.

In this article we will introduce the concept of simple design and get into the context of programming with the 4 rules of simple design according to Kent Beck.

We are going to take the time to explain each rule of Kent Beck to understand the right way to program.

Without further ado, let's start by defining what simple design is.

What is simple design in general?

Simple design is the art of designing processes that consist of simplifying the processes of our activities or our works. Anything that is characterized by being the simplest, most concise, most precise with the fewest possible elements is considered simple design.

For example, when you use a remote control, you sometimes don't need to read the instructions before understanding how to use it.

Sometimes you don't even need to observe the tool too much before mastering it.

This does not mean that you have become an expert in remote control but rather that the latter has been designed in such a way that you understand immediately how to use it.

How does it work? with very small details such as the layout of the keys, the small logos and the colors placed on the special keys.

The set sends you a clear and concise message on how to use it with simple and minimalist visual elements.

In the field of products intended for trade, a good designer will have designed a product sheet that will allow you toapprendre easily how to use the product, why it can be used in this way and, always with the minimum of elements possible, show you why it is worth this price.

Often in the designs of works, objects that use the concept of simple design are very minimalist.

They are rarely overloaded with superfluous, complex objects or practical use that gives the impression that you have to be an expert to use them.

The concept of simple design does not always apply to physical works and products.

The concept can also be applied to processes, work methodologies and also to our lifestyle.

In the rest of our article we will show you the questions you need to ask yourself to start creating objects, processes or methodologies following the concept of simple design.

We will then tell you about the consequences of simple design in the world of computing.

Question to be asked to apply the concept

The simple design retains in a very minimalist way the essential of what one needs for each thing.

To make a clear, concise, unambiguous and minimalist design following the principle of simple design, you must ask yourself the following questions:

Is it necessary?

Is it of any use?

Is this the easiest way to communicate this idea?

Can I break it down into simpler parts?

What are its potential impacts on the environment?

The consequences of simple design in software engineering

In the field of software design commonly called software engineering, simple design has generated various practical concepts and even religions around source code production and maintenance.

You have certainly already heard of refactoring, design patterns, software architecture, etc. etc… These principles meet the need to always simplify the source code of software in order to obtain quality software.

This process of source code simplification falls within the application of simple design in software design.

In computer science more precisely in the field of application development, the older a source code becomes, the more complex it becomes, often because of the needs of customers who are more and more demanding.

The more the code is clear, simple, concise and precise, the more it is of quality and even better it makes it easy to work as a team on it to maintain it.

Now that you have an idea of what simple design is in the context of application development, let's explore the 4 rules of simple design following Kent Beck which constitute even today, the foundation of the writing of a quality code.

The 4 rules of simple design according to Kent Beck

In this post I will introduce concepts that I believe encompass the whole principle of simple design in the field of application development.

These are the rules according to Kent Beck to apply simple design in software design. (source: ).

These rules, you will see, are rules on which many paradigms, techniques and know-how have been built to maintain the quality of the source code without making it incomprehensible or complex.

In this section we will discuss Kent Beck's four fundamental rules for writing simple and easy to understand code.

We recall that Kent is the father of the XP Programming and TDD (Test-driven development), a development process where testing is at the center of all the validation process.

His book was successful in putting code testing first before any code writing.

What at the time was not a common programming practice and still remains a counter-intuitive practice today.

In the field of programming, a simple and easy to understand code allows for quality development.

UConfusing, hard to understand, and overly complex code very quickly leads to shoddy software and hell of bugs for the development team.

In this section we will discuss the four rules for designing a simple and rigorous code. Its rules present as commandments are listed in order of precedence.

We distinguish in particular:

1- Pass the test

2- Reveal the intention

3- No duplication

4- The fewest elements.

The 4 rules of simple design according to Kent Beck

We will take the time to explain each of your rules in the following part.

Let's discuss the most important and highest priority rule: Pass the test.

1- Pass the test

This rule is one of the most important and also the most difficult that can be applied in programming. But I assure you that it is effective when you apply it very well.

The principle means that before you even write your first line of code on software features, you must write their tests. In my case I often proceed by the unit test.

Testing the software before even writing the code that will work on this test is a counter-intuitive but still effective practice in software development.

The goal is to be able to install a rigorous framework to code without exceeding the product specifications.

Concretely, here is point by point what this practice brings to our activity:

The test makes it possible to communicate the design of the program to other collaborators or to oneself.

Thanks to the test we can say specifically when we have finished developing a feature or a system. You will understand later why!!

The test prevents the destruction of the code during modifications, updates, additions of functionalities and also during the transmission of the code to other developers.

Personally, unit tests specifically have served me many times as an example of using a function. For example when I discovered a function of which I do not understand how to use it, I can see in the file test how it is used. I can use unit testing to experiment with portions of code.

You will have understood writing the test first is very required to lay the foundations for well-designed and quality code.

According to the author of his rules it is not recommended to write code in anticipation of what will be done later.

For example I have already met colleagues (even at home until today) designing an architecture and coding portions of the software based on a future use of the program.

Instead of focusing on the current use, I write code thinking that we will reuse it later in another way.

In the end you end up with complex code, with complex, super-too-flexible designs that won't be used for years.

Take the test first is really the basis of all good simple source code design.

This eliminates any fear of destroying the software when modifying.

This also allows us to validate the plan we had made for the software.

The three following rules will allow you to validate the quality of your source code based on the first rule which is passing the test.

The second priority rule is the revelation of intention.

2- Reveal the intention

Now that you have written the test of your software, during the coding you should focus on reveal the intention of each portion of your code.

Concretely, this means that in practice the class name, variables, functions and even methods must express what you want to do with them.

The following examples are well explained in the book and the video of clean code.

You can follow this long and comprehensive video series to learn more about Clean Code and the art of reveal your attention in the source code.

Programming is not an intelligence contest , that's why a complex code difficult to understand is not the code to keep for its software.

For example when you write a function, the name of this function must say what it actually does.

Each function or each method must have thatone responsibility.

This means that they must deal with one specific problem at a time. Each problem constitutes a feature or a class.

An important part is also the use of comments.

Code that you need to read the comments to understand is complex and bad.

Comments are not intended to explain the code we are writing.

Comments should say why we are doing this feature or writing the code this way instead of explaining what the code is.

You will understand what we mean by the revelation of intention in his code.

Kent's following rule has the same priority as the following section and should, in my opinion, apply alongside what we have just seen.

The next rule is to avoid code duplication.

3- No duplication

This means that the code you write must be unique throughout your database. A piece of code or function content needs to be written only once.

This duplication elimination rule is well known by the acronym of DRY which means Don't repeat yourself.

When we say to avoid code duplications, it doesn't just mean to avoid writing the same algorithms. It should be understood that there are two types of duplication:

There are code duplication : which is really the easiest to identify . It's practically the exact copy-paste of what we wrote in a piece of code.

Then there is what is called duplication of knowledge: this type of duplication is very subtle to detect, but once extracted it greatly simplifies the source code.

The rule of non-duplication applies a lot to the last because it is more difficult to find and once we manage to identify it, we can largely simplify the basis of our source code.

Now that we have passed the test and we have written a very simplified code without duplication and easy to understand, we only have to check that we have written it in the simplest and most concise way possible.

Without this last part we will not talk about the simple design. Discover the rule of the smallest element.

4 – The smallest element

After revealing the intent of your function and applying all code reduction rules eliminating duplications, all that remains is to keep the smallest element of your code.

This last rule will allow you to both validate everything you have done and remove what does not fit within the scope of your program specification.

With this rule, Kent goes much further by saying that any portions of code that were not specifically mentioned in the design should be removed.

You should remove any code that your program doesn't use or really doesn't need.

Sometimes during our programming work, we needed to write parts or portions of code because we thought we would need it later in the near future for the purposes of the project.

At the end of the product when you realize that this portion or functionality has not been used as expected, it is recommended to remove it entirely.

Now that you've finished applying these four simple design rules, all you have to do is practice applying it incrementally on a regular basis.

The more you practice, the better you master.

Subscribe to our newsletter ! It's free !

We have defined what simple design is and how it has allowed designers to create products and processes in the most simple and efficient way possible.

We also talked about the influence of simple design in computer software design and how to apply it by following the 4 rules of simple design according to Kent Beck.

As a reminder, the 4 rules are:

1- Pass the test

2- Reveal the intention

3- No duplication

4- The fewest elements.