[zimablue]

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.