Most “Clean Code schools” treat it as a kind of personal mastery. You achieve certain skills and levels, learn patterns and practices. But how does Clean Code relate to technical debt in a modern, team oriented DevOps world?

Development of a Developer

I tweeted about this a few weeks ago – and the tweet got viral and had more than 100k views in one day.

So here is the full story.

Dev after one Week

A new developer does not understand the language they use. They normally start with a template or by “googling” a solution and modifying it. They are not aware of security and performance implications of the code they write.

Dev after one month

While the developer learns new things, you can see it in their comments. New developers tend to comment what they do – and not why they do it.

Dev after one year

After one year, the dev learns a lot about security modifiers, performance implications (like const and static) and they add them to their code. They also learn about xml comments and automatic documentation and they add them everywhere (even if no documentation is generated).

Dev after three years

After three years, the developer learns a lot about error handling (mostly by debugging their own code). You can tell this state if the dev is building their own logging and error handling framework. We’ve all been through this…

Dev after six years

The dev knows a lot about design patterns, inversion of control and dependency injection. It is normal for them to develop their code with TDD and of course they use DI containers in every project. They can discuss their choices with others and know a lot about SOLID design and principles like KISS, DRY and YAGNI – but they do not have the feeling yet when to apply which of them.

Dev after ten years

If a dev really masters all these skills, they start to value simplicity. They start to use patterns only if they are needed and they reduce code fragments that are unnecessary (like default security modifiers). They also only add comments if they are needed – for example to document a decision or to generate help.

The problem is that at this stage you cannot tell from looking at the code what the developer knows. The code might just look so simple that it could be from a greenhorn.

Clean Code is team sport

Today we normally don’t write code on our own – we work in teams. It does not make sense to look at personal mastery to detect clean code. The team must have the ownership of the code – and not the individual developer. So how does clean code look like from a team perspective?

“Clean Code is the absence of technical debt”

What is technical debt?

Features are visible and have a positive value to the end user. Bugs are visible but have a negative value. But you can also create value that is not visible – for example if you change the architecture or automate something. The negative value that is not visible is called “technical debt”.

Technical debt arises every time you take a shortcut. Every time you don’t write all the tests you should. Every time you don’t update the documentation. Every time you don’t fix the code analysis warnings and so on.

How to deal with technical debt

Technical debt is not something bad. Without technical debt, you could not release anything because writing the “perfect code” would be too expensive. The problem arises if the technical debt grows so big that you cannot release new functionality because of the debt.

The solution is to keep the debt at a certain level and do not let it grow beyond that. You have to manage technical debt and keep it at a certain level.

Manage technical debt

To be able to manage technical debt you first must define it. If you understand what the technical debt is for your team, you can measure it and control it by adapting and modifying the KPIs. You can include the review of the KPIs in your Sprint practices and in your definition of done.

„If you can’t measure it, you can’t manage it” (Robert S. Kaplan)

Technical debt is not only about static code analysis! It also includes software design, code metrics, documentation and testing. Measure it, create a baseline and do not let it slip under that baseline.

Summary

Instead of focusing on a personal view of clean code, we should switch to a team view and a common understanding what clean code is for our team. Let’s switch our focus from clean code to technical debt. This does not mean that we should stop writing clean code! Clean code is more important than ever. But we need a shared understanding what it is and we must be able to measure and manage it.