One of the hardest challenges of paying off technical debt is that there's no visible improvement to the stakeholder. From a business perspective, they often think it's working now, why not leave it alone?
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.
>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.
Good technical debt... well, what's the expected lifetime of a piece of software? How long do you think it'll be maintained and growing, before it is either no longer relevant/needed, or replaced by a new product?
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.
Technical debt it the intentional decisions you make to go faster. You can pay it off or not if you want to.
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).
I've come to the sad conclusion that excessive code quality is a smell. And most attempts to head off technical debt are really just premature optimization, which is its own sort of evil.
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.
That is the benefit, shipping quickly. It is exactly the same benefit as financial debt: It lets you start working now.
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.
I wrote an essay about communicating to stakeholders the value of paying down tech debt. If I wrote it over again I'd amplify the section called "Later".
> One of the hardest challenges of paying off technical debt is that there's no visible improvement to the stakeholder. From a business perspective, they often think it's working now, why not leave it alone?
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.
There's an argument that it's only technical debt if you're paying interest on it. i.e., it is costing you something: time, pain, preventing improvements, etc.
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.
I think an interesting way to address this impact, is to start adding more time to each task and address it as technical debt, which is both informative and actually true.
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).
> Other than the benefit of shipping quickly.
How about the benefit of not having to pay the full cost ever if the early release disproved the business case successfully? That is a big financial saving for the stakeholder.
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.)
You need to tie it to a business need. I have a single project which is being reviewed for both performance. If you don't need a new feature, why change the code? If you do need a new feature: offer a trade-off. You can do it quickly, buy it will be slow, or you can take additional time to improve the performance. Which choice you makes depends on your performance benchmarks/buckets.
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.