You can keep paying the interest, and sometimes that’s the right move. The point of the metaphor isn’t that it’s impossible to keep running a business on technical debt - just that it costs you a little bit every day.
Yeah precisely - it’s area under the curve of ongoing costs to morale, time to modify, etc. Not often something that comes in all at once.
Unless you let it fester really badly.
Part of the problem with the ongoing cost thing is that it’s a bit like slowly draining the oxygen out of a sealed container, replacing with nitrogen as you go. By the time you know what’s happening, you’re already dead.
These aggressive, widespread tropes around “clean” code and combating technical debt are recruiting our culturally reinforced notions of hygiene and threat so that we are alert to nitrogen replacement in our atmosphere.
I asked Ward Cunningham, who coined the term “Techinical Debt” why he did it. He explained to me that he used that term because he tried to explain to business people the tradeoffs they were making when creating the schedules they did. That there would be some shortcuts technically so the project would ship on their schedules. He used it because business people don’t understand metaphors such as entropy or keeping a clean shop.
He also explained to me that technical debt is not a bad thing if managed. It isn’t a bad thing if it means more customers and money. Being in debt shouldn’t be the evil thing us nerds have made it out to be.
I personally don’t like the term. Because the analogy breaks down and also because I hate finance terms. Because the reality of debt is that between equals, you can always renegotiate.
I think this is a really unappreciated point. Debt isn’t bad. Excessive debt can cause problems, but it’s very possible to make payments on a controlled set of technical or financial debts.
I’ve renegotiated technical debt before! In my case it meant identifying a feature that was especially painful: weekly manual intervention was required to make it work. The “debt reduction” we put in place was to turn off the feature until we could make it work properly. But to do that I had to convince product management that we were better off eliminating that feature than limping on.
You don’t always have pay off the debt you created
Not if you leave the company before the bill comes due or you rewrite the whole system from a spec.
Don’t have a spec? Well, look at how California’s state employee payroll system is going :)
The article was good, but the conversation happening here in the comments is more revealing. What I’m hearing is that there’s wide agreement that framing engineering quality issues as technical debt has been highly effective at getting management to take it seriously, and that in fact things may have gone too far in that direction. :)
It’s a good conversation and I won’t repeat what you all have already said. I do think there needs to be understanding that some debt can be okay - a principle with which finance agrees. I don’t think the framing needs to change.
As a disconnected observation, to mitigate debt you need to have the ability to repay it even in the face of surprises. As an individual with student loans, say, you do this by having a steady income. The technical equivalent is to have enough engineers on a project. As long as you have people who know your stack and can devote time to fixing it should that suddenly become more urgent, your debt is covered.
No conclusion from there. :) Just extending the metaphor.
There was an article that appeared on lobsters a few months ago that describes technical debt as unhedged call options that pairs neatly with this blog post.
I much prefer that unhedged call options metaphor.
Holy… I wouldn’t want to take over after this guy.
And then? :)