3 ms·

I disagree with your definition of technical debt. Decoupling everything as much as possible may be good (or it may over complicate the problem) but technical

I disagree with your definition of technical debt. Decoupling everything as much as possible may be good (or it may over complicate the problem) but technical debt occurs when you don't do things like that, whatever you define as the "proper way", for sake of expedience or lack of experience. All software has some technical debt but you can have more or less depending on how much effort you or your organization takes in reducing it or avoiding it from the start.

zzzcpan 10y ago
> but technical debt occurs when you don't do things like that When you don't do things like that you may or may not simply weaken your flexibility or/and simplicity. It doesn't mean that it's a bad thing or a debt, because you have no idea whether you you may need any of that later. Long-term software projects, for example, might benefit from DSLs so much more, than solving those problems on a lower level with all the decoupling and everything, is it a debt then? Absolutely unclear. Because it's all about productivity and risks and all of the non-measurable things.