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 non-linear 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.