How to use the term technical debt to mean anything you want
There is no tech bankruptcy or tech extradition
Technical Debt is a made-up term. It is meant to bring to mind financial debt in which you borrow from your future to accomplish something in your present. Then, it becomes the future, and you have to pay for the past. Sometimes, you do this on purpose as a calculated risk, like when you open a loan to start a business or attend college. Other times, you do this because of your own stupidity, like when you take out hundreds of micro-loans to pay for burritos.
People who work in software think of these two definitions for technical debt:
A positive investment, like college: We made an investment in something and are now working to pay it off. We will come out ahead.
A negative mistake, like burritos: We made a terrible mistake and have learned little, but please give us time to try again.
But there are many other meanings for technical debt:
when you make an engineering decision that makes sense at the time, but then conditions change, and the way you handled the tradeoffs makes less and less sense every day, and you need to change the system to be more in line with the current constraints.
when you build a system and about halfway through, realize that the architecture is not going to work, but you just keep going, and from that moment on, rather than call it regret, you call all your work technical debt.
when you are asked to build a prototype, a proof of concept, and then when the demo goes well, you are immediately asked to turn it into a product and given an unrealistic deadline, and you realize that the proof of concept was a trap that you fell for, but you will need to turn it into a real product sometime after it ships and catches on fire immediately. This work to put out the fire and install fire alarms is technical debt.
when you create Version 1 of a system very quickly, and this creates a business but not more jobs so that people can help you work on the system. The system works but is slow and just sort of falls over all the time. So someone asks you to build a Version 2, but it is just you, and so you build Version 2, and it’s a little better because it only falls down on Tuesdays. Then they ask you to build Version 3, but nobody is coming to help. This process is called technical debt snowball.
when you create Version 1 of something, and this creates a business and a lot of other jobs, so suddenly there is an entire team of software developers making changes to Version 1, and you need to coordinate and create systems and tools and processes, and you should have already done it because people are stepping all over each other and there really isn’t a way to test the software before users test it for you for free, so you have to do a lot of work to go back and create tools and logging and monitoring and branching strategies and deployment plans, and the people outside your department don’t understand any of this because they thought you said it was done and they are cashing checks at the bank so you explain it as technical debt that needs to be paid off.
when Developer A creates a version of something that Developer A loves but Developer B hates, it is labeled tech debt by Developer B when they get promoted.
when you build a great system, but it depends on a component that releases a new version or is hacked or decides to sell ads or does something else you don’t like, or everyone stops working on it, or you suddenly realize it is under GPL, so you take on this emotional debt and upgrade all your systems.
when a developer doesn’t like the way something works and wants to change it for reasons they can’t explain and that are completely disconnected from reality. Tech debt is then an umbrella term for something nobody understands that the developers want, and we are tired of hearing about it.
when you don’t like the way something works and want to change it for good reasons and are asked to explain it, and you use all the usual metaphors like system upgrades or migrations or legacy migration or infrastructure investments or innovation or future-proofing or engineering hygiene or scalability or developer experience until you remember which magic word works at this company to get work approved: technical debt.
You could take it to another level too. It's technical debt, that accrues interest that if you don't change the components of the system, even if they become older and broken, over time it becomes harder and harder to modify or change the system so that in effect the longer you don't change the core components, the more you have to spend in total to maintain the legacy system to the point where the total time to actually replace the core components is less than it would have taken to replace the system had you not earlier, because of customisation and tight coupling etc. I have seen this taken to the extreme where these components live way beyond their supported life. At this point you're effectively paying the total cost of ownership and support of the system components and the customisations. If it's not open source you may be out of luck from any vendors, who would refuse to support the components unless you upgrade.
- when you release an API without a single byte of documentation and suddenly everyone is reaching out to you asking to explain how it works