I'm not so sure if it's 'lack of understanding' of some other tech. And it's not 'debt' or rather, only debt in a certain context. It's highly rational to exp

I'm not so sure if it's 'lack of understanding' of some other tech. And it's not 'debt' or rather, only debt in a certain context. It's highly rational to expend minimal energy trying a new feature, because time to market is key, and so is the fact that there's a good chance nobody will want it. 'Debt' is only ostensibly incurred once the feature actually works, thus there's real material value to be gained whereupon the ostensible refactor becomes impending, and therefore seen as 'debt'. The 'debt' didn't materialize in a bunch of other things because they were dumped. I also don't think anyone has too much trouble with understanding this, the operational issue is that 'technical debt' will always be put alongside 'shiny new feature' in terms of priority, in which case it becomes much less amenable for investment. To put another way, and this hurts all of us Engineers at a deep level: The most efficient perpetual state of code may be messy, unfinished and have bugs outstanding. Just let that one sink in: in a situation of ongoing feature development which yields benefits to userland, the optimal level of 'completeness' of most code is literally 'never really complete'. Bugs and ugly architecture likely represent a more efficient operating state when we consider value creation as the real goal. The more 'core' and longstanding a bit of code is, probably it makes more sense to go after the technical debt because the yields of the effort are pervasive. But for many other things, nope. If you're building a home to last 500 years (ie Europe) you want a solid foundation, if you're building it only to last maybe 50 years before they tear down and put up something new, then some things are less important.