Clean Code is a team sport!

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.

1_week

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.

2_1_Month

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).

3_1_Year

Dev after three years

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

4_3_Years

Dev after six years

The dev knows a lot about design pattern, 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 yet have the feeling when to apply which of them.

5_6_years

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.

6_10_years

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 and Technical Debt_logo

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 from a team perspective look like?

“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

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.

Magaing Technical 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 KPI’s. You can include the review of the KPI’s in your Sprint practices and in your definition of done.

Manage_Debt_Circle

„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 it under that baseline.

Technical Debt_Workflow

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.

DevOps_Rad_logo

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s