On Technical Debt: Shoveling forward
A lot of what we do in the tech world is based on analogies. Learning, concepts, discoveries, and teaching is all heavily based on that. If other sciences worked the same, we'd have 'gut-tubes' instead of intestines, probably. In any case, our understanding of concepts is often dependent onto the quality of the analogies chosen and how far we are willing to push them.
Technical debt falls right into that pattern. Technical debt is in fact often explained handwaivingly by saying that there is some bad stuff that happens in code and it accrues over time, and it's a good idea to spend time to fix it, whatever the causes of debt may be. When it comes to discussions about prioritizing tasks, features, or any other sort of code-related decision-making, technical debt comes with the general idea that you can take more time to do something right, or make a quickfix and accumulate debt.
You can then take some time at a later point and pay down that debt and eventually avoid going bankrupt. That's usually fine. The problem becomes that sooner or later, people start misinterpreting the original intent and thinking of technical debt the same way you could think about financial debt: a lever to use in order to get something now and then pay the accrued cost progressively over time. This is however not how things feel from the technical person's point of view.
I'm far from being the only one with this concern as multiple blog posts have been written on this topic before.
Rather than focusing on why that is wrong, I want to propose an alternative analogy to describe the reality behind technical debt.
French Canadians have an expression called 'pelleter par en avant', roughly translating to 'shoveling forward'. The idiom simply refers to the act of shoveling snow off of one's driveway by pushing it ahead and pushing forth. Shoveling the snow forward, while efficient at first, eventually compounds and means that each additional bit of driveway uncovered requires an ever-increasing amount of work.
image from La Presse
It is a better idea to take the time to move manageable amounts of snow around and never exert yourself to the point of a heart attack.
The colloquial expression is commonly used when referring to debt, specifically government debt, with the idea that spending now is leaving the consequences for future generations. This tends to work fairly well for regular debt, but I feel it works even better for software.
Shoveling forward means that not only we're making things harder for the future, but any and all changes and modifications done to code in that direction demands greater effort, and increasingly so. You cannot ignore debt until a later point. It is not an astute strategy to later pay back what we do not have today: it is a shortcut that works in a single direction, for a brief period of time, and then makes everything else more difficult right away.
The only way to fix it is by attacking whatever snow we have pushed ahead of us and getting rid of it, or working in another direction entirely, abandonning the halfway dug path we've made for ourselves and working another way. It is otherwise easier to avoid the problem by not doing it in the first place; accept that near-term work may take longer, but won't create far more problematic and exertive obstacles right in front of us.
The analogy is probably not perfect, but it at least feels to me like it communicates the reality of quick dirty software fixes better.