He introduces it in a presentation seen on Skills Matter, but also elsewhere. And it’s used to solve a very important problem: How to explain the nature of technical debt to a non-technical stakeholder. Technical debt is a somewhat esoteric idea to a non-techie, and in Lukas’s case he needed to explain it to a very important non-technical stakeholder—a new shareholder. This shareholder is directly funding Lukas’s team, so it’s essential they are comfortable with what they’re spending their money on.
the economic cost to change the system exceeds the needed return for most changes.
In other words, it’s when it’s no longer economically viable to change the system. And, he points out, this can be the case even if the software is stable and working. It’s a statement about the economics of change, not the economics of the status quo.
Lukas further proposes the idea that the likelihood of actual bankruptcy is quite high if you’ve got technical bankruptcy, which is pretty easy to see, and so this should now be meaningful to any non-technical stakeholder. The problem is that technical bankruptcy is almost always recognised too late, which means the organisation is likely locked onto a track to economic bankruptcy.
Technical debt, then, is (roughly) the work needed to avoid technical bankruptcy—to ensure changes remain economically viable.
In the video Lukas spends a lot of time looking at equations to model this, and drawing some conclusions about how to avoid or manage technical debt. But even without the equations this is of enormous value. I hope more people can use this idea to help non-technical people understand the importance of tackling technical debt, and why technical people worry about it.