The 4 rules of simple design according to Kent Beck

Last update September 29, 2022 at 05:51 am

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 will 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.

 

The 4 rules of simple design according to Kent Beck Click to tweet

 

 

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 some questions 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. It's about rules according to Kent Beck to apply simple design in software design.

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

 

In this section we'll talk about Kent Beck's four basic rules for writing simple, easy-to-understand code.

 

We recall that Kent is the father of 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 but Confusing, difficult to understand, and overly complex code very quickly leads to poor quality software.

The main reason is mainly that the developers logically will not understand each other and one will end up creating bugs in the long term.

In this section we will discuss the four rules for designing a simple and rigorous code. Its rules are in order of priority. We distinguish in particular:

 

1- Pass the test

 

2- Reveal the intention

 

3- No duplication

 

4- The fewest elements.

 

In the rest of our section we will develop these rules. Without further ado starting with the first, most important and highest priority of the rules.

 

 

 

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 extremely 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 practice but is still very effective in software development.  The goal of writing the test first is to be able to install a rigorous framework for coding without exceeding 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 that I don't understand how to use, I can see in the test file 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 necessary to lay the foundations of a 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-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 the function of one of your programs or the name of the function must say what it does concretely.

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. A code that we need to read the comments to understand it is complex is bad. Comments are not intended to explain the code we are writing, comments should say why we do this functionality or we write the code in this way instead of explaining what the code is.

 

You will understand what we mean by the revelation of intention in his account. Kent's following rule has the same precedence as the next section and should apply alongside my personal opinion. There is not one greater than the other.

The next rule is to avoid code duplication.

 

3- No duplication

 

 You took that one of each thing must be said only and only once. This means that the code you write must be unique throughout your database.

This duplication elimination rule has seen a lot of progress in two code simplification I have several programmers applying it including myself. Certainly you have heard of the dry method which means do not repeat yourself.

 

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

There is side duplication: which is really the exact duplication of what we wrote in a piece of code.

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

The non-duplicate rule applies a lot on the last one because it is more difficult to find and once found makes it possible to greatly simplify the base on our source side.

 

Now that we have passed the test and we have written a very simplified code without duplication and easy to understand, we just 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.

Discovering 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 delete what does not fit into your program.

 

With this rule, Kent goes much further by saying that any code that was 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 all you need to do is practice applying it incrementally on a regular basis. The more you practice, the better you master.