Picture of Stefan Lieser
Stefan Lieser

Clean code is not a dogma

Clean Code

The term Clean Code was coined by Bob C. Martin and his book of the same name. Shortly after the book was published, Ralf Westphal and I Clean Code Developer initiative and compiled 45 principles and practices. Clean Code, the book, was a stimulus for us to deal with the topic. We drew on various sources and some of the principles were already discussed in the 1970s. Here you can find, for example a PDF from Parnas from 1972 on the idea of modularization.

What do all these trends have in common? The aim is to linearize the course of costs, as shown in the following figure.

001 Das Problem mit Kurven clean code

Whether we talk about clean code, clean code developer or software craftsmanship, the core issue is always to make software projects manageable by keeping costs linear instead of increasing exponentially.

Principles and practices

Principles and practices help us to do this. Here is an example: If we ensure in the code that a method or class has exactly one task, it becomes easier to understand the code. This ensures that Single Responsibility Principle (SRP) for a linearization of the cost curve. Code that we understand easily is easier to change or add to. The same applies to practices. For example, we recognize through Continuous Integration problems in the code more quickly because everything is regularly integrated. Practices also contribute to the linearization of costs.


But this is where it gets exciting: does this mean that the principles and practices must always be adhered to? Are they the top priority? The answer is obviously no. At the top of the list are the Values. For example, it is about Changeability or Correctness. How these values are achieved is only the second question we ask. The answer is often to adhere to a principle or apply a practice. Here we are close to the concept of dogma.

According to Wikipedia the term Dogma in antiquity "the decree issued by rulers and thus not to be questioned". Obviously, we should not see principles and practices of software development as a regulation that has been issued by someone and is not to be questioned. Nevertheless, the question arises in detail as to whether, for example, principles should never be violated. Is there any leeway here? Are the Clean Code Developer principles and practices an opinion that can be followed or not?

Clean code training

Closed company courses

We conduct all seminars as closed company courses for you.

If you are interested or have any questions please contact us.

Necessity instead of dogma

Of course, the composition of the Clean Code Developer building blocks is somewhat influenced by our views. This cannot be completely avoided. For example, TDD is deliberately missing and only test-first is mentioned. I have already written about the reasons for this here (https://ccd-akademie.de/tdd-vs-test-first/). Nevertheless, our compilation provides a number of building blocks that lead to the overall goal of achieving the values of changeability and correctness. Should the building blocks now be viewed dogmatically and always adhered to? No. A differentiated approach is required. As a guide, it is imperative to think about the principles and check them in the code review. It is not a question of dogma, but of necessity. If we do not take the principles and practices into account, the increase in costs will be exponential. As this is not acceptable to our clients, following clean code is a necessity.

Clean code is a necessity. If you don't work according to the rules of the art, you will quickly fall behind.


The good news is: relax. The principles do not have to be adhered to dogmatically. But the other message is: clean code is a necessity. Sooner or later, at least in a competitive environment, it won't be enough to just bang out your code. Principles must be observed, practices must be introduced and practiced in the team. In every situation, you have to weigh up what is important at the time. Sometimes a principle must be adhered to in every case, sometimes other things take priority. A dogma might even be simpler, but its effect would be too simple. Just blindly adhering to any principle does not lead to the goal. A team needs a clearly structured way of working. This process must ensure that all important steps are taken that lead to high-quality code.

P.S. The following tools may be able to help you:

Our seminars

Clean Code Developer Basics

Principles and tests - The seminar is aimed at software developers who are just starting to deal with the topic of software quality. The most important principles and practices of the Clean Code Developer Initiative are taught.

to the seminar "
Clean Code Developer Trainer

Conducting seminars as a trainer - This seminar is aimed at software developers who would like to pass on their knowledge of Clean Code Developer principles and practices or Flow Design to others as a trainer.

to the seminar "
Clean Code Developer CoWorking

Online CoWorking incl. coaching -
We are often asked what developers can do to keep up with the topic of clean code development. Our answer: Meet up with other Clean Code Developers online on a regular weekly basis.

to the seminar "

2 thoughts on “Clean Code ist kein Dogma”

  1. Pingback: 4 reasons not to write clean code - CCD Akademie GmbH

  2. Pingback: 7 reasons for software companies to book a Clean Code Training - CCD Akademie GmbH

Leave a Comment

Your email address will not be published. Required fields are marked *