Clean code is not an end in itself. And no dogma, like me elsewhere have already established. The Clean Code Developer Principles and practices serve this purpose, Achieve values. When coding, these are primarily the values Changeability and Correctness. The value of the Production efficiency.
In order to arrive at a differentiated view, it is helpful to identify situations in which it is about something other than the values of changeability and correctness. I have identified four such situations:
1. fix a very critical bug
Not every bug is critical. But if nothing works for the customer, Production is readya lot of money is at stake, then clean code does not play a role at first. The aim is then to rectify the fault so that the customer can continue working.
It is better not to get into such a situation. It causes enormous stress and damages your good reputation. Not using clean code at such critical moments, even though not using clean code initially led to the problem, sounds paradoxical. This is resolved when the rest of the process becomes clear: after the problem has been solved, automated tests must be supplementedto ensure that this problem never occurs again. And this is usually accompanied by Refactorings connected, with which the code quality is slightly improved.
Conclusion: the root problem is the missing Clean code focus. In this situation, the focus is on the bug fix, followed by a clean-up.
2. learn technology
If you want to use a technology from which you no idea you would do well to do this in a separate project to do. In particular not in production code. Such Spikes serve this purpose, Gain insights. It is therefore important to change the focus. It is not about the changeability and correctness of production code, but about the Exploration of a technology.
At the Learning automated tests can help. Instead of writing a console application to execute the code, a test can also take on this role. It may also be important to find out how the new technology behaves in automated tests.
ConclusionWhen learning, the goal is to gain knowledge. If the Clean Code Developer principles and practices support you in this, great. If not, leave them out.
Receive an excerpt from the book "Mit Flow Design zu Clean Code".
3. check the solution idea
For some requirements, a solution must first be checkedbecause no one in the team is sure that it will work like this. A Proof of Concept (POC) can help to gain confidence here. Similar to learning a technology, this is also the case when testing a solution idea, Gain insights. The goal is not the production code, but the realization of whether a solution idea works.
Tests can also be used to make rapid progress in the POC, for example. It is not forbidden to apply clean code developer principles and practices. However, the focus is not on the longevity of the code. That's why it's okay, not to have high demands on code quality in a proof of concept. At the same time, the code must prove that the solution actually works. In this respect, the readability and comprehensibility of the code is not unimportant here.
Conclusion: Testing a solution idea is not yet about production code. At this stage, it is still unclear whether the approach will work. The focus is therefore on gaining knowledge rather than on changeability.
4. check product idea
As Startup it is important to find out quickly, whether a product idea will work. There are various procedures for this, which will not be discussed further here. At some point, you reach the point where a first product version must be created. As it is not yet reliably clear at this stage, despite all the preparatory work, whether the whole story will work economically, the effort must be kept within limits. It may also be necessary to pivot the product again.
Here you find yourself in a dilemma. On the one hand, the code should be changeable so that it can be easily adapted to a change in the product idea. At the same time, everything has to progress quickly because there is a lack of cash flow. I wouldn't completely do without the Clean Code Developer building blocks, but I would apply some things with a sense of proportion and postpone others until later.
But be careful! "We'll do that later" can quickly lead to a mountain of legacy code. As soon as the first paying customers arrive and the product is up and running, it needs to be tidied up. There must then be a good balance between new features and tidying up.
ConclusionThe balancing act between quality and cash flow is difficult.
Conclusion
The Clean Code Developer Principles and Practices are enormously important. In the past and currently, too little of this has been implemented. And yet there are times when the focus is on other things. This is not an excuse or an argument for doing nothing. Code quality is important, Clean code is important.
We may currently be in a phase where we are starting to shift priorities. With the advent of very powerful AI tools such as ChatGPT, the actual code can already be generated many times over. The focus is therefore shifting even more towards automated tests. If the code behind it fulfills the tests and can be generated again and again, quality will no longer play a role in the future.
What reasons do you have for not writing clean code?
English 
German
1 thought on “4 Gründe, keinen Clean Code zu schreiben”
Pingback: Become a Clean Code Trainer - CCD Akademie GmbH