Stephan Schmidt - September 18, 2025

Refactoring - Everyone Gets It Wrong

What refactoring really is and how it helps removing technical debt

When talking to CTOs, many of them talk about technical debt and how it hinders their development and demotivates developers. Technical debt makes development more risky, slows it down, and makes introducing bugs more likely.

In the same discussion, refactoring comes up. A refactoring of their code is necessary and would help them get out of technical debt. Developers push for a refactoring and business pushes for more features.

This is a false dilemma.

The misunderstanding at its core is what refactoring really is. Developers think refactoring is a major undertaking, rewriting code for weeks to clean everything up. If you read the refactoring book though, refactoring is changing the code with small changes to improve the design and keep the exterior behavior the same.

If it takes several weeks to get out of your technical debt, it’s not refactoring but a rewrite.

Instead, refactoring means constantly changing the code. During development of a feature, if the design can be optimized, refactor it. At the end of developing a feature, if the design of the code can be improved, refactor it. Constant refactoring keeps the code clean, flexible, and readable. Constant refactoring prevents the need for a rewrite.

As CTOs, push developers to constantly refactor code to keep it clean and top notch. As CTO, shield developers from business pressure to deliver features with low code quality.