// and how much is attributable simply to accumulated bloat or other things that might fall under the vague label "technical debt." (I am the person you're res

// and how much is attributable simply to accumulated bloat or other things that might fall under the vague label "technical debt." (I am the person you're responding to) - I do think that very often it indeed falls into the vague label of "tech debt" but not all debt needs to be repaid. For example - let's say I am writing a new Turbo Tax feature and I can do it quickly by leveraging 4 existing APIs. My feature is "slow" because each API does its own complex IO operations, many of which are redundant across the 4 calls. Is that technical debt? I have the opportunity to create a new API that optimizes the IO for my use case, and it would be 4x faster. But, it may never be "worth it" to do that because my feature is seldomly used and is still fast enough for the user to not lose productivity. So I would say that's not really a tech debt, just a technical tradeoff that was made. In general, I find that a lot of latency comes from (a) reuse of suboptimal pieces/frameworks that accelerate development and (b) not taking the time to optimize. There are times when these are tech debt, and there are times when these are fine.