Also, the metaphor starts to fall apart if you consider good debt vs bad debt in terms of financial investments. No examples of good technical debt come to mind, other than the benefit of shipping quickly.
I think that's where the metaphor works best. Good technical debt lets you ship sooner than you otherwise would have, similar to how a mortgage lets you afford a home sooner than you otherwise would have. Paying interest isn't ideal, but it may work out a lot better than renting. Likewise, code cruft isn't ideal, but shipping 6 months sooner might pay off a lot more than having a perfect code base can.
A pretty good talk from Railsconf a few years back. The debt metaphor can be thought of as two axis: planned vs unplanned, and low vs high interest.
If you explain to the stakeholder that by not paying down technical debt, they're only paying off the interest, but they have to keep paying it forever, perhaps that will sink in. The opportunity cost of those interest payments is profit-generating work. By failing to address technical debt they are constraining the business.
Technical Debt is something for which you have a repayment plan and a timeline on which it will be repayed and you are making the repayments.
Technical Tax is everything else. And your tax rate will keep climbing higher and higher unless you make a change at the policy level.
Over the right time scale, technical debt can be a huge win. That's "good debt".
Consider the race against time - either time to market (get a product out the door asap, for valid business reasons), or because it's currently in proof of concept stage and will either be replaced or fixed later, once it becomes a real project destined for production. In either case, technical debt is a good deal. Even if it costs you more in the long run, the time saved in the short run can be the difference between success and failure.
These are the justifications that lead to Technical Debt.
Unless you write a self destruct system that prevents the software from starting after a certain date... there is no such thing as 'good debt'.
Projects come from POCs, they get moved into Production and are never replaced, just patched.
Unfortunately every project I have been on has very little of this. The real problem I see are not intentional decisions, but "If only I had known". The team that choose a framework and 3/4ths the way though the framework company dropped the product (I know a product shipping on WinCE 6 - MS dropped support for that on them 1 week before code freeze). The team that started on some new fad that seemed good only to be the first to find the issues when used in their situation (the fad is overall good, but the limits are not understood).
Don't burn the village in order to save it.
I think you need to answer why shipping quickly would benefit the company. Shipping quickly is not an end but a means to an end. The point is the state of the market and the impact you plan to have on it, with an added constraint of some deadline.
Perhaps it’s an AR app a company wants to ship in time for a sporting event or art show, and the business has only enough runway to get to a potential windfall of revenue from it?
That being said I think for tech debt to be “good”, the real challenge must be well understood, as well as the alternatives, it must be documented somewhere and all stakeholders must be aware of it, because I’m going to force them to consider it in every prioritization meeting until it’s done or not needed any more.
Personally, if I have a client that’s constantly questioning my expert analysis, the thing for which they entered into a contract with me, I would question whether that relationship should continue. Seeking info is fine and expected; shutting it down is not.
Technical debt is good if what you can create quickly and dirty actually improves your productivity. That is what tools can do.
In the real world if I incur in debt and my debt pays for a tool like a car-truck that lets me move myself and my things faster, I am improving my productivity. Sometimes tens of times.
Think of the difference between a sewing machine and hand sewing. Hundreds of times slower.
I can pay back my debt faster with good debt.
In software, if I can make a tool that in a quickly and dirty way is able to do things in seconds that take me hours and fatigue me, then it makes sense.
Sometimes you can even use your quick and dirty tool in order to clean the dirtiness of your own tool way faster. That is what bootstrapping is all about.
That is what compiler writers have always done. They started in assembler, then created the core of the language, and then they used their own language in order to improve the compiler.
Other writers used languages like Lisp with super slow compilation, most of the time interpreted, in order to create the core of the language in days instead of years.
You don't see the benefit of shipping quickly. For me it is one of the most important things in the world. People's salaries cost more in direct proportion of the time it takes to do something.
https://medium.com/@brlewis/fighting-technical-debt-in-an-ag...
I think the article somewhat addresses this where it talks about not needing to pay off debt in areas where it doesn't need to be changed, so perhaps it's a valid argument that if it's "working now" to leave it alone. As for the hard challenge of when to pay off (or accrue) technical debt, it really comes down to individual judgements from an experienced technical leader who has a high level and long term frame of reference. The focus should ultimately be on optimizing delivering overall value to the company or mission. One thing to avoid is to have non technical managers making decisions about technical debt, since it will likely be an uninformed decision.
Consider a financial instrument that is interest only on a perpetual timeline, and you are not required to pay down the principle. If the cost of paying the interest forever is still less than paying down the principle, why wouldn't you just keep paying interest? Like you said, it takes an experienced, competent leader to make a good judgement about what the true costs are either way.
For example after a few months of no refactoring, you start adding 10% to all estimations based on technical debt. It grows more the more refactoring is kept at bay. Similar to how we add a certain percentage to each task for communication, bug tracking, qa, scope changes or anything else. You can keep an arbitrary count, and perhaps even have a "technical debt" reduction amount for certain backlog tasks.
I haven't ever tried this though. But it's an interesting way to communicate technical debt (and is very close to the metaphor).
It's the same as buying insurance, it reduces risk and exposure in exchange for money. Ask management if they want insurance or risk and cash. You pay money to reduce risk. It's a decision they are capable of making when put into non technical terms. They assume the risk of catastrophic failure if they dont buy insurance. (Obviously major refactoring has its own risks.)