Summarizing the article (?) I wonder whether there’s a way to split this concept of technical debt into two axes.
If you do waterfall, your code is technically “simple”, because it has a nice architecture, but it’s “misaligned”- it won’t fit the problem well because it hasn’t been tested. This seems like the ur technical debt.
If you code to solve every problem as fast as possible and patch/rip it up to stay close to the domain- now your code is complex/ugly because design philosophy has been neglected, but it’s well aligned to the problem, call that modern tech debt.
So you have two axes, ugliness/beauty and misalignment/“fit”. Modern practice says to focus on iterating fit quickly then more occasionally solve beauty, in big steps. So aesthetic debt vs alignment debt.
If you do waterfall, your code is technically “simple”, because it has a nice architecture, but it’s “misaligned”- it won’t fit the problem well because it hasn’t been tested. This seems like the ur technical debt.
If you code to solve every problem as fast as possible and patch/rip it up to stay close to the domain- now your code is complex/ugly because design philosophy has been neglected, but it’s well aligned to the problem, call that modern tech debt.
So you have two axes, ugliness/beauty and misalignment/“fit”. Modern practice says to focus on iterating fit quickly then more occasionally solve beauty, in big steps. So aesthetic debt vs alignment debt.