Re:How to approach and prioritize technical debt
by lowbloodsugar on Monday January 31, 2022 @10:59PM
(#30158460)
Still not debt. Still not how anyone, anywhere would describe debt.
There are plenty of situation, outside software, where doing something simple now results in something more complex later. Nobody calls that debt. MBAs don't call that debt.
What you describe there is actually an ideal conversation, and when presented with that choice, managers can make the right choice for them. What you are describing is scoping, done right.
The debt there is knowing that "we will spend $500k more doing it this way (interest) but we will benefit in the meantime".
There are other factors too that make the true cost of the debt higher. For instance less flexibility as requirements change. I often find myself saying "this would be an easy change if we had initially built it in the more extensible way, but at the time you didn't need/want for extensibility so now your easy feature is actually a large refactor"