Technical Debt is a term used by non-professionals as a euphemism for their own incompetence. I say this not to cut people down but with all due desire for us t

Technical Debt is a term used by non-professionals as a euphemism for their own incompetence. I say this not to cut people down but with all due desire for us to get better at our work. It's a lot harder for someone to say "I didn't know how to solve this" and much easier to say "It would take longer to solve it the right way." Because of this you should take claims fo "Technical Debt" with serious suspicion -- and given how fuzzy the general concept is and how enabling it is, I think the proper response is to find it useful far more for personal ego management than as a respectable tool for thinking about execution of software projects. There is no innate conflict between solid decision-making in a software system and execution time. Generalizations take longer but generalizations or lack thereof do not imply sound architecture; this is orthogonal concerns. But solid execution (decoupled components) is a skillset question. In fact if you have the skillset it often takes longer to make a bad decision. Technical Debt doesn't respect this (i.e. skills/mastery) and is only good for deflecting from our incompetence and thus keeping us from acquiring the necessary skillset.