(This is not disagreement with the original post, but further musings.)<p>One of the other problems with the technical debt idea is, debt relative to <i>what</i>? Since I think most people do not consciously instantiate an answer to that question, I think most of us non-purposefully choose by default a comparison to an idealized perfect code base that is somehow perfectly correctly factored, yet also as fast as completely optimized code, completely documented without being overdocumented, simultaneously optimized for all possible future changes, and despite not existing at the moment, also perfectly understood by the original team such that they can do anything they like to it, and such understanding will survive any such refactoring, all accomplished in exactly the same amount of time that it took to write the terribad code that we actually have.<p>OK, but that was never on the table, though. What I described isn&#x27;t even possible to manifest, and even if you back it down to what is at least sort of possible, you don&#x27;t have the resources to manifest it before you simply run out due to lack of customers. You&#x27;re not really taking on &quot;debt&quot; if you fail to manifest that, any more than you are taking on &quot;debt&quot; if you fail to make every possible dollar you could if you perfectly correctly harnessed your skills and made the perfect deals.<p>I think what a lot of people call &quot;debt&quot; is simply the natural state of code. Debt is something somewhat more exceptional than that. There is a core idea of value there, because there definitely is an operation where we deliberately make a short-term choice at the cost of long-term pain, but it requires more thought than I think has traditionally been given to it. The baseline needs to be more carefully defined.<p>As I said at the top, I&#x27;m just musing here; I don&#x27;t have a ready-to-go definition of &quot;baseline quality&quot; here.