Technical debt's main difference from financial debt is that it can't really be quantified, because it's hard to really identify. Most software has a lifetime, initiatives don't maintain economic value indefinitely.<p>At the end of that lifetime, the lights get shut off and the code mothballed, never to see the light of day again. At that point, the balance sheet hits zero and you never have to pay it back.<p>Software where this doesn't happen eventually has the kinks filed away. Old Fortran codebases and the like have fixed maintenance costs and are worked on by savvy greybeards who are excellent at providing their own job security. Nobody wants to rock that boat, and nobody does. The greybeards are the ones who pay off the debt because it's their livelihoods that get threatened by instability. Management just keeps happily writing checks, devoting their attention to squeakier wheels.<p>So it's a tradeoff. Initial greenfield development by one dev or a small team eventually gives way to the bread-and-butter of keeping projects responsive to economic needs. What we call technical debt is really just architectural problems made both from inexperience, and from not specifying the requirements of the project well enough.<p>Decisions made by the greenfield team add to the friction that the maintainers experience in steering the ship. The problems need to be identified and corrected in the course of the maintenance. Unfortunately most devs are not really capable of remaining productive while fixing architectural issues, so management perceives this as prioritizing the needs of the devs over the needs of the business and so tend to balk at putting resources into paying off debt.