3 ms·
It's a good question, because all software has "technical debt". Which means "technical debt" is not a real thing, but a concept invented out of a limited under
by zzzcpan 10y ago
It's a good question, because all software has "technical debt". Which means "technical debt" is not a real thing, but a concept invented out of a limited understanding of the problem. Instead, there is always a tension between a simple solution and a more flexible one and there is always a way to make things simpler or more flexible or even more complex and less flexible. For many problems the key to keep both simplicity and flexibility is to decouple everything as much as possible, i.e. share nothing, functions, not object with methods, scalar arguments, not complex structures, libraries, not frameworks, etc., but there is still a lot of room to do it better, like DSLs, metaprogramming.
- wvenable 10y agoI 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.