What is the root cause of missing code refactoring?

Clean Code is a challenge for every project, team and software developer. Theoretically you could write this Clean Code right away, and that’s it. But when many programmers are working on the project then each person has a slightly different programming style. Additionally, each person has a different understanding of the Clean Code concept. Moreover unfortunatelly programmers often change jobs and new ones join the team with different ideas about code quality …

So how did I find the root cause of the lack of Clean Code?

For the first 10 years, I was “only” a programmer. Back then, I saw the world through technology rather than the client’s business needs. Therefore, during my trainings, the most important for me were the techniques of code refactoring. The training participants were very pleased with the emphasis on the almost exclusive technical aspects of Clean Code that they could learn.

As times was going by, I was asking the participants of my workshops how they applied the acquired knowledge of refactoring in practice. I was curious if they promoted / shared the habit of keeping code clean by refactoring.

Unfortunately, each participant of my workshops almost always had an excuse.

• manager’s consent would be needed
• there is not enough time for this
• I will not be the only one who is refactoring…
• the others are not refactoring any code as well…
• we have such tight deadlines
• and so on…

Then I started looking for a common part of these issues. Convincing programmers, managers, analysts, etc. – that it’s a never-ending story worthwhile (and quite an old movie). It is true that I started with this approach for a while – but with little success.

Then I started my wide research for what is the common ground for all these problems. When will all these challenges not block refactoring? And I think I found it! Well, all these excuses have one thing in common. It is a false assumption that refactoring is a separate, additional activity.

Code refactoring only takes place in the project when it is part of the software development process. Refactoring to Clean Code cannot be considered a separate and additional activity.
– Włodek Krakowski

What are the consequences of this false assumption?

If code refactoring is considered to be an additional thing, there will always be an excuse to skip it. After all, since it is a separate thing, it is not necessary…

The client is waiting “only” for functionality

The client is waiting for functionality that will provide business value. No client is waiting for code refactoring! So what for shall I perform code refactoring?

But don’t programmers expect high code quality in order to be able to continue the project? Otherwise they will be looking for a new job because of clutter in the code! Is it only the client who is really important? How about the comfort of the programmer’s work? Can the comfort of developers’ work with Clean Code be omitted for the sake of client?

Refactoring is not a step in the software development process

Since refactoring is not mandatory, we don’t add it to the software development process. This allows us to skip refactoring to clean code without too much thinking. Probably (at the beginning) writing code will be faster. We will be able to say that “this is the process we have … so it’s not my fault that we have bad code instead of clean one”

But could we skip refactoring if it was a separate and visible column after the “code review” in the Kanban / Scrum board? It can also be a more general column like “Rework” – that covers things like introducing missing tests. The process is here to ensure the presence of individual steps.

The manager’s consent would be needed

If there is something extra, someone should agree to it. Because it will take time, which means it will cost extra money. Then I can say that I would love to refactor my code every day, but my manager does not allow me to do it…

But would anyone be asking for permission if refactoring as part of the process and good practice of the team? After all, it is the manager who is responsible for the compliance of the process with the agreed standards in the company. The standards could contain activities to keep Clean Code.

It would take time

“We don’t have time to make the code clean” – how many times have I heard that … And then I ask – “Do you also have no time to correct the defects reported by the clients?”

Is it better to prevent or cure? Is it better to act proactively because you can predict problems that will arise? And then these issues will take our time and money anyway, whether we like it or not … Perhaps we will proactively spend less time and money working earlier on the code quality and architecture…

Refactoring is an additional cost

This is true. I couldn’t agree more with it. Refactoring to Clean Code takes time and money!

But is the lack of a Clean Code and the mess cheap? Is bug fixing free? Will we actually save money in the long run by skipping refactoring to clean code?

I am afraid of the consequences of failure

If I am working on something additional that is not necessary, I absolutely want to be successful. But refactoring is a journey and a search for a better code. Sometimes an attempt to improve the code fails and you need to roll back the changes.

Success is about going from failure to failure without losing your enthusiasm.
– Winston Churchilli

Successful people are constantly learning. The rest think they already know everything.
– Harv Eker

So if you learn from your failures and mistakes, you grow in your skills. Only the ones who proceed with challenges make mistakes. So, a failed refactoring effort can be a lesson to come up with new ideas for changes to Clean Code next time. Does your employer support development through experiments that are sometimes unsuccessful?

Advice for developers

Start by code refactoring

Assess the quality of the existing code that you will be working on. Perhaps it is already difficult to read. Then following the current architecture – adding extra conditions and making methods longer – will only make matters worse. So perform refactoring to e.g. design patterns before adding new functionality. Then adding a new strategy pattern or command class will be simple and legible.

End up by code refactoring

Often times, the need for refactoring is invisible until the code changes are finished. And that’s good because thanks to this we avoid early “over-engineering”! Therefore once changes are implemented and covered with tests it will be easy to refactor to Clean Code.

Refactor while programming

Multiple refactorings are small tweaks that you can complete on the fly within seconds. They are the extraction of a method, variable, field, or their absorption. Similarly, renaming a method or variable. Use these functionalities on a regular basis as they are automated in many environments such as IntelliJ, Ecplise, and Rider.

Spread the word. Share this post!