> I think that quality is something you can't 'bolt on' later. It has to be built in, top to bottom, throughout your organization, code base, and personal skills.
I agree with all of your points and just wanted to add one more thing that doesn't seem to be addressed much. The author mentioned technical debt didn't have an "interest rate", but it absolutely does. As soon as you start to add debt to a particular part of the code base, it must be paid back immediately the next time you or someone else has to work on that same section. This may genuinely not matter for a one-off script, but if it's code that will ever be worked on again it can start a snowball effect that causes the interest to compound and usually manifests itself as code that's buggy, unstable, and hard to work on.
What do you think of this extension of your analogy:
Financial debt has an interest rate, but you take it out because you believe the return on the proceeds raised adds more value than the cost.
Technical debt is meant to (ideally) be the same. As long as it's outstanding and compounding, it should be because your return on business value will be lower if you "pay it back", then if you do not and spend time/resources elsewhere.
if your discount rate is 30%+ per annum, this makes for some counter-intuitive conclusions about when it's smart or not to "finance" with technical debt.
I agree with all of your points and just wanted to add one more thing that doesn't seem to be addressed much. The author mentioned technical debt didn't have an "interest rate", but it absolutely does. As soon as you start to add debt to a particular part of the code base, it must be paid back immediately the next time you or someone else has to work on that same section. This may genuinely not matter for a one-off script, but if it's code that will ever be worked on again it can start a snowball effect that causes the interest to compound and usually manifests itself as code that's buggy, unstable, and hard to work on.