I love the metaphor of technical debt: consciously opting to take the easy way out in the short term, explicitly accepting a more painful route down the road, because having a quick solution in the short term will give you the wiggle room to absorb the pain in the longer term.
Like taking out a loan so you can start a business, which allows you to pay it back with interest.
I also like the metaphor of technical debt for what it does not say. It is unwise to take on debt without a plan of when and how to pay it back, especially if it doesn't buy you anything in the meantime.
Likewise, technical debt is not a licence to take a shortcut to make an arbitrary deadline, thereby risking being held back when faced with an actual deadline.
@vinnl In my opinion a better metaphor is dirty dishes.
With the unhealthy attitude much of the world has about debt IRL, the underlying assumption is that you can take on debt without ever expecting to pay it back (and you can just declare ontological bankruptcy if it gets too bad).
Dirty dishes on the other hand NEED. TO. BE. CLEANED. Want to make a meal? Gotta clean those dishes first.
Unless you are running your software company like a bunch of college students who figure they can just buy new dishes or eat off of plastic cutlery for every meal... which would be stupidly expensive and wasteful, and describes much of the same behavior that people operate under when using the "tech debt" metaphor.
@vortex_egg Hmm, but what I'm missing there is that, in the debt metaphor, it can be a valid choice to take on debt even though it means you will pay more in the end. But is there ever a good reason to put off doing those dishes?
Debt can be compensated by other assets. Tech debt doesn't care that your NEW code is good. Financial debt won't bite you as long as you can make small payments on it. Tech debt will.
Finance has a perfectly good word for the concept of technical debt. It is called "risk".
@michiel @vortex_egg Often, I think tech debt *can* be compensated by other assets. For example, if a system is hard to change unless some foundational work is put into it, an alternative system might be able to serve a similar use case. (Though I am making some assumptions here about what "compensating debt by other assets" means.)
And I would certainly argue that you can often avoid paying off tech debt by piling up small workarounds, but the amortised cost will only get higher - like debt.
@vinnl I agree, and it's also interesting how different people perceive technical debt differently. Some just don't care, and others never want to compromise. I like this piece Martin Fowler wrote on the topic :). https://martinfowler.com/articles/is-quality-worth-cost.html
Something else that's interesting is that it isn't always clear when you're doing a disservice by trying to fight "technical debt". You may be thinking that your solution is great but you are actually overengineering and shooting yourself in the foot.
@noeldemartin Great article, and a good illustration of your last point: if it *doesn't* make future changes cheaper (ie overengineering), it's not improving the quality.
(Of course, this isn't always easy to predict.)
The metaphor of cleaning the kitchen is a good one too: you can postpone it if you're hungry, since it's worse to do it when hungry, but it will be more work later.
@vinnl technical debt is IMHO more akin to climate change. Think about it ;)
Server run by the main developers of the project It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!