Tech debt is a myth
Posted on Jan 16th, 2022

My favourite chapter in Eric Evans's Domain-Driven Design book is called "Breakthrough".

It describes how returns from refactoring are not linear. Sometimes one small change has a much bigger impact than a preceding series of improvements. Author calls these impactful changes breakthroughs.

Importantly, Evans defines breakthroughs as events and not as specific techniques. There's no way to design them, but it is important to recognise these opportunities when they occur.

He writes: "The transition to a really deep model is a profound shift in your thinking and demands a major change to the design. On many projects the most important progress in model and design come in these breakthroughs."

This nonlinear nature of refactoring returns is exactly why I don't like the term "Tech Debt". Say, I have $1,000,000 debt, every $1 I return removes $1 from my debt. With tech it is not like this at all. $1 of investment into refactoring can result in $1,000,000 value. And likewise $1,000,000 can result in just $1 of value (or even negative value). And also these changes are not completely independent. Sometimes the first $999,999 will not give us much value and the remaining $1 refactoring will suddenly make a huge difference.

Instead of "debt", we should rather think about it as threats and opportunities. Our decision making model is much more similar to an act of investment rather than to borrowing money. Refactoring is much more than just cleaning-up your codebase. And even simple clean up should be happening with a threats and opportunities mindset. Otherwise cleaning just for sake of it can be very subjective, and can make code even worse.

There's no way to measure tech debt. There's only a backlog of known design issues, workarounds and hacks. And there's no way to estimate coverage of this backlog.

But without a way to measure, can the refactoring be ever completed? Solving all known problems will never let us cross the imaginary balance line, because this line is a mirage. In fact there's no negative and no positive state of a codebase. There's only its current state. That said any change makes it better or worse, there's just no equilibrium, no line to cross.

In a world where it is impossible to foresee all risks and opportunities, dealing with uncertainty is the crucial skill. It is important to get rid of the linear cleaner attitude and to embrace the nonlinear investor attitude as part of the culture. As a team, be ready to recognise your next breakthrough.

Do you have a question on this or maybe a different opinion?
Send me a private message
Do you want to know about new posts?
Follow me to receive updates
Latest publications
Jul 5th, 2022 Solution Ownership Apr 18th, 2022 Behind a good process Jan 16th, 2022 Tech debt is a myth Dec 28th, 2021 Note-taking mistakes Nov 19th, 2021 Bundling and Unbundling Oct 26th, 2021 Product insights Sep 21st, 2021 Clarity of purpose Aug 15th, 2021 The power of simple rules Jul 28th, 2021 Growth by doing Jun 19th, 2021 The Systems Lens May 25th, 2021 Research, Shaping, Making Feb 25th, 2021 Running a remote team Feb 12th, 2021 Low risk integrations Jan 19th, 2021 Your very own third party service Jan 8th, 2021 The three types of work