Quite a few good points, and a decent summary at the end: >> Refusing to pay financial debt has ethical implications that refusing to pay tech debt doesn’t hav

Quite a few good points, and a decent summary at the end: >> Refusing to pay financial debt has ethical implications that refusing to pay tech debt doesn’t have. Paying off tech debt generally involves redoing previous work, destroying previous investment. You could say that "tech debt" always originates from a lack of understanding or a lack of time (deadlines or rushed work). So the term "debt" is indeed not that helpful to think about it. In the first case, the lack of understanding when trying to create complex systems is most often unavoidable, even for experienced devs. Trying to correct too often too soon will be a problem here too. It's a fine line: too many mistakes accumulate, and you will be unable to make any progress anymore, and the cost of cleaning up everything might be too high. On the other side, trying to clean up everything as the smallest issue is noticed will make it very hard to go through an "exploratory phase" fast enough to gain the required insight, and a lot of issues are only understood once systems are up and running, so you kinda have to try to get there anyway. The better devs you have here, the better they will be able to ride this whole process. For deadlines and rushed work, I think "technical debt" is pretty fair already. Because while sometimes the result of rushed work is basically the same as the previous case where what you lack is understanding, the process and the context is very different. Many devs will know that what they are doing is not solid, stable progress, and won't be happy about leaving it there forever. It's not a side effect of trying to learn, but instead trying to deliver, and that makes people much more uncomfortable. Also, it's much less gratifying having to work hard when you know what you are doing is not even good progress, but just a crutch. In the side of context, there's also the fact that on a rush there's often poor planning and goals are prioritized without much consideration for the path to reach them. The lack of a clear path has consequences. So I think that although code can be "equally bad" on both situations, there are significative differences, and maybe we should treat each case separately. You really need to reserve some time after sprints and rushed work if you want to keep moving ahead confidently afterwards. So "debt" doesn't seem wrong there.