The article makes a comparison between tech debt and financial debt and argues that tech debt is not inherently bad, as long it is managed correctly. This involves ensuring that the income...
The article makes a comparison between tech debt and financial debt and argues that tech debt is not inherently bad, as long it is managed correctly. This involves ensuring that the income generated from new features outweighs the debt incurred from bugs.
From the article:
A simple kind of high-interest short-term debt would be committing code without tests or documentation [...] the revenue (and customer feedback) you get from shipping fast can outweigh how much more bug-prone you made the code in the short term.
If you take a single pull request (PR) that adds a new feature, and launch it without tests or documentation, you will definitely get the benefits of that PR sooner.
Every PR you try to write after that, before adding the tests and docs (ie. repaying the debt) will be slower because you risk creating undetected bugs or running into undocumented edge cases.
If you take a long time to pay off the debt, the slowdown in future launches will outweigh the speedup from the first launch.
Interestingly, I learned more from the financial side of this article than the technical side. I think I intuitively understood that some technical debt is acceptable if repaid in a reasonable...
Interestingly, I learned more from the financial side of this article than the technical side. I think I intuitively understood that some technical debt is acceptable if repaid in a reasonable timeframe, but didn’t really have any understanding of financial debt other than “try not to have it.”
Great article that I can both relate and probably put to some practical use. I work as a team lead in software development so tech dept is one of the things I have to manage and balance....
Great article that I can both relate and probably put to some practical use. I work as a team lead in software development so tech dept is one of the things I have to manage and balance. Developers have a tendency to want to reduce all tech dept to zero, but we also have to work on some new features at least once in a while and not simply make all the legacy stuff perfect.
I liked how the article spent time on all the uncertainties. Interest rates are easy to calculate and reliable, but our estimates are usually wrong and with increased tech dept it becomes impossible to give reliable estimates on any sort of feature. Something that sounds simple enough to everybody will become increasingly difficult with tons of legacy tech dept, because no developer can see all the side effects beforehand.
That is why I like to be very transparent on all our tech dept and continously remind management what the consequences of not dealing with specific sub projects and their tech dept will be. Usually things work fine now, but some places our code base has written itself into a corner, so that minor feature they might have in mind require a bigger rewrite. Especially because we have never deprecated any feature so far.
"Paying off tech debt" is complicated because it is pretty much the case that the only way to have zero tech debt is to have zero tech. Ideally, the famous XKCD chart (https://xkcd.com/1205/)...
"Paying off tech debt" is complicated because it is pretty much the case that the only way to have zero tech debt is to have zero tech.
Ideally, the famous XKCD chart (https://xkcd.com/1205/) could be used to decide if it's worth it, but your point about interest rates vs tech costs is spot on. It's way harder to figure out how much it's costing you, how much you can fix it (ie vs just doing debt swaps) and how long it'd take to fix the unknowns.
The article makes a comparison between tech debt and financial debt and argues that tech debt is not inherently bad, as long it is managed correctly. This involves ensuring that the income generated from new features outweighs the debt incurred from bugs.
From the article:
Interestingly, I learned more from the financial side of this article than the technical side. I think I intuitively understood that some technical debt is acceptable if repaid in a reasonable timeframe, but didn’t really have any understanding of financial debt other than “try not to have it.”
Great article that I can both relate and probably put to some practical use. I work as a team lead in software development so tech dept is one of the things I have to manage and balance. Developers have a tendency to want to reduce all tech dept to zero, but we also have to work on some new features at least once in a while and not simply make all the legacy stuff perfect.
I liked how the article spent time on all the uncertainties. Interest rates are easy to calculate and reliable, but our estimates are usually wrong and with increased tech dept it becomes impossible to give reliable estimates on any sort of feature. Something that sounds simple enough to everybody will become increasingly difficult with tons of legacy tech dept, because no developer can see all the side effects beforehand.
That is why I like to be very transparent on all our tech dept and continously remind management what the consequences of not dealing with specific sub projects and their tech dept will be. Usually things work fine now, but some places our code base has written itself into a corner, so that minor feature they might have in mind require a bigger rewrite. Especially because we have never deprecated any feature so far.
"Paying off tech debt" is complicated because it is pretty much the case that the only way to have zero tech debt is to have zero tech.
Ideally, the famous XKCD chart (https://xkcd.com/1205/) could be used to decide if it's worth it, but your point about interest rates vs tech costs is spot on. It's way harder to figure out how much it's costing you, how much you can fix it (ie vs just doing debt swaps) and how long it'd take to fix the unknowns.