Update 14.02.2024: This article has been slightly revised.
About the short-sighted decision to develop quickly instead of cleanly.
Anyone who is familiar with the principles and practices of Clean Code Developer initiative will find that it takes time to use all the building blocks. There are building blocks that quickly become good habits for a developer. For some, this may be adherence to code conventions, for others the consistent use of version control. However, there are also developers who struggle with these two building blocks.
The question then quickly arises as to why it should be so important to commit your code to version control several times a day. Or whether it is not Riding on principles insist on compliance with code conventions. However, the question often arises when we come to the principles that need to be dealt with more intensively before they can be put into daily practice: Does it have to be? Do I really have to follow all these principles and introduce all these practices? It takes a miserable amount of time, during which I have long since coded the feature. Clean or fast?
Clean code - a contradiction?
It seems to be a contradiction: when software is clean according to the rules of the art is to be developed, it takes longer. So what do I gain from regularly implementing the Clean Code Developer building blocks? The colleagues who don't care deliver faster. So why "clean" if it takes longer? You can find the answer in the adjacent figure.
Increase in costs
The diagram shows how the costs for a feature develop over time. If a feature is implemented very early on, it is implemented quickly and therefore costs less than at a later stage. One reason for this is the size of the code base. Of course, it is easier to make an addition to a code base with a few hundred lines of code than to a code base with a few million lines of code. Nevertheless, the goal remains Linearize the increase in costs.
The green curve shows the desired cost trend. The increase is still taking place, but only linearly. It is equally necessary for software projects and products, prevent the exponential increase in costs. Once the effort in a project is on the steep upward path, the team has a massive problem. Implementing new requirements and fixing bugs takes longer and longer, the costs run away. At some point, the customers will also run away. There is therefore a risk of loss of revenue and ultimately insolvency. Now, not every company goes bankrupt because a project requires more and more resources. And yet this is a huge problem for companies.
There is nothing good unless you do it
Now the article could end here, because the illustration obviously shows the need to work cleanly. When looking at it, the time perspective makes all the difference. If I look at a project in the short term, I am faster if I ignore some principles and practices. Omitting automated tests is very popular. However, if I take a long-term view of the project, this omission will catch up with me. There comes a time when I no longer understand the code, make a mistake and wish I had written tests. Adding these is time-consuming. Often the structures are already set up in such a way that tests are difficult to add.
Perhaps an analogy with health will help. What happens if I don't do any sport this week? I gain time for other things. Cool! To conclude from this that sport is overrated is certainly wrong. In the long term, my fitness will suffer, ultimately my health. So I have to motivate myself to do sport every week. This is one of the most important contributions to staying healthy in the long term. Is regular exercise a guarantee of health? No. The situation is similar with the Clean Code Developer building blocks. Do they guarantee that projects will run smoothly? No. But this does not mean that I can do without "clean" and therefore make faster progress. In the short term yes, in the long term no.
What can provide support?
At this point, the question arises as to what a team can do to keep up regularly. The Clean Code Developer building blocks are important. I have very rarely met developers who seriously question the meaning of the principles and practices. And yet it is difficult to apply them in daily practice. What could help? As the CCD Academy, we have a lot to offer:
Clean Code Developer postcard set. Available here in our store.
Clean Code Developer playing cards. Available here in our store.
The Clean Code Developer Poster is available download here.
You can purchase these tools for little money. Once the postcards are on my desk, they keep reminding me to follow the principles and apply the practices. The poster on the wall is also a reminder of the theme. And last but not least, the playing cards are a good reference tool for finding the right argument in a code review or retrospective, for example.
We can also help with our training courses. If the entire team takes part in training over a period of six months, this will improve the way we work. To do this, we spread the training days over the period and meet online for a single training day every 3-4 weeks, for example. In this way, a training measure has a greater impact than with the classic 3-day seminar "en bloc".
Receive an excerpt from the book "Mit Flow Design zu Clean Code".
Conclusion
Rushing out another feature might make the boss happy. But he will be just as unhappy if it turns out after a while that the house of cards that was built up in a hurry is collapsing. So it doesn't help. As with sport - there is no way around regular clean code.
How do you answer the question: clean or fast?
English 
German