Three questions about clean code

by | 31.10.2024

A conversation with Stefan Lieser about clean code, its introduction in companies and its application in the age of AI

How can software be developed efficiently and sustainably at the same time? And what can companies do to improve the readability of the code, reduce errors and simplify long-term maintainability? One answer to these questions is: clean code.

Stefan Lieser is an expert in clean code and flow design and co-founded the Clean Code Developer Initiative at the end of 2008. He works as a trainer and consultant on the topics of Clean Code Developer, creation with flow design and software architecture. In his book ‘Mit Flow Design zu Clean Code’ (With Flow Design to Clean Code), the managing director of CCD Akademie GmbH describes a software development process that focuses on the systematic decomposition of requirements and design. This makes him the right person to answer the following three questions:

What is clean code?

Stefan Lieser: The term goes back to the book of the same name by Bob C. Martin, which was published at the end of 2008. [1] In it, he describes various principles that lead to code that is easy to understand and easy to test. My colleague Ralf Westphal and I took the book as an opportunity to launch the Clean Code Developer Initiative. [2] We have compiled 45 principles and practices there. These principles and practices each contribute to the four values of correctness, changeability, production efficiency and continuous improvement.

At its core, clean code is about creating code in such a way that costs are minimised over the entire lifetime of the software. To achieve this, the code must be easy to read and understand, otherwise it will be expensive to expand. Furthermore, automated tests are absolutely essential, because otherwise the costs for the correctness aspect would be too high.

For me personally, clean code is what we have compiled in our initiative. The goal is the four values mentioned. We can achieve these by observing principles and introducing and applying practices.

How can you introduce clean code into a team and keep it alive?

Stefan Lieser: I recommend a number of measures for this. For many teams, it is helpful to start with a training session. This gives them the necessary know-how. Furthermore, it leads to a common understanding and a common language within the team. Unfortunately, the prophet is often not heard in his own house. Here, too, training can help to overcome resistance by providing an external perspective.

After that, a regular ‘Clean Code Meeting’ should be arranged to take place weekly. Of course, recommending another meeting carries a risk. To avoid jeopardising efficiency, the meeting should not take longer than 30 minutes. It provides space for all questions related to Clean Code. Scheduling a fixed meeting for this offers the advantage that the topic is really taken seriously. Everyone in the team then knows that there is a fixed appointment when they can discuss their questions and challenges. However, the topics should not be fully discussed in depth in this meeting. This can be done afterwards on a smaller scale with two or three developers to save time and effort.

Another recommendation is regular code reviews with the whole team. As long as the code is not regularly reviewed together, everyone is ultimately doing their own thing. However, joint communication is necessary to set standards and ensure that they are adhered to. These code reviews have a different goal than reviews in private, which are often conducted asynchronously. These can be a quality gate and may make sense for some teams. But that’s not the kind of communication across the whole team that I’m talking about.

As a third measure, a monthly pizza and beer meeting can be arranged, at which each developer in turn prepares short presentations. It promotes communication within the team and challenges the ability to prepare and present complex interrelationships. As long as Clean Code only takes place in the minds of the developers in the company, it will not last. It must become visible and for that we need these regular joint meetings. Speaking of visibility: our Clean Code Developer poster, postcards and playing cards also help to raise the profile of the topic. [3]

And I have a bonus tip: even with self-organisation, it helps to have a team lead to drive the topic forward. And management must also be on board. If the company is large enough, a Clean Code Advisors team can also help to support colleagues.

Is clean code still necessary in the age of AI?

Stefan Lieser: As long as AI ‘only’ provides us with code snippets, it is imperative that developers continue to ensure that the code is of high quality. Perhaps we will get to the point where we feed the requirements to the AI and the complete code comes out the other end. That would then tend to make it the product owners’ responsibility to formulate their requirements precisely. But we are not at that point yet.

So far, the AI is a tool that supports us in our daily coding. It makes us significantly more productive. At the same time, however, it is still our responsibility to test the code generated by the AI and to ensure good readability. The AI may still throw out messy code. This is probably because the AI only produces what it can derive from patterns in existing code. And of course there is a lot of dirty code of inferior quality there. It will be interesting to see how the tools will develop.

Another challenge has not yet been solved by AI either: software needs a structure. No matter how much you love the principles, it is not enough to work only at the level of methods and classes. Someone also has to think about the structure, and that means, above all, dealing with the dependencies of the components. Clean architecture is the keyword. To do this, it is necessary to create a design. Because you only come up against a limit with the principles alone, I wrote the book ‘Mit Flow Design zu Clean Code’. It deals with the question of how to design software in an agile framework. And this is still a task that AI does not support. In this respect, clean code and clean architecture remain relevant topics for all developers.

 

Notes (Links partly in German):

Stefan Lieser’s CCD Academy offers various training courses in which participants learn the basic skills needed to write Clean Code in their daily work through a wide range of practical exercises.

Stefan Lieser - clean code and flow design expert

[1] Robert C. Martin: Clean Code: A Handbook of Agile Software Craftsmanship
[2] CCD Initiative
[3] CCD poster as well as postcards and playing cards

Here you will find information on the topic of flow design.

Stefan Lieser has published an article on the implementation of clean code in the t2informatik Blog.

If you like the article or want to discuss it, please share it with your network.

There are more posts from the t2informatik Blog series “Three questions …”, including

t2informatik Blog: Three questions about e-learning tools

Three questions about e-learning tools

t2informatik Blog: Three questions about software development

Three questions about software development

t2informatik Blog: Three questions about digital transformation

Three questions about digital transformation

Michael Schenkel
Michael Schenkel

Head of Marketing, t2informatik GmbH

Michael Schenkel has a heart for marketing – so it is fitting that he is responsible for marketing at t2informatik. He enjoys blogging, likes changes of perspective and tries to provide useful information here on the blog at a time when there is a lot of talk about people’s declining attention spans. For example, the new series “Three questions …”.