For example, in an early startup, you make a decision that will be somewhat expensive to pay for later, but now, doing it "right" may be unaffordable (e.g. too late to market, not enough features, etc.).
An experienced technical leader can make a conscious risk assessment and choose to incur in tech debt now and pay the cost later and focus the meagre resources of the startup in parts that have a higher chance of ensuring the survival and success of the company.
If they're right, and you succeed, if the risk calculation was correct, you now have enough resources to repay that debt, if not, nothing was really lost.
Tech debt can be accidental too, for example due to lack of experience with the codebase by some engineers, or by accumulation of unintended consequences.
In these cases, once it's discovered an experienced technical leader should make the risk assessment: do we invest now or later? Is this good enough for now?
In any case, it should always be managed to your advantage and paid when it's best for the team.
I have seen the result of projects where the team was overly obsessed with tech debt. The code may look nice, but there is not a lot of it, and the products are invariably feature poor and do poorly when real users get them in their hands. The team was so inwardly focused and they forgot the real world and things like users and features and market realities.
Some tech debt, some dirtiness and rough corners, show a living, breathing product reacting to its users and market and prioritizing value. But make sure you’re aware of what you’re accruing.
Hard agree. So much so that throughout the setup I was feeling eager to share this with my own team, and by the end I couldn’t think of any reason why I’d want to do that without writing my own follow up article.
And—probably because I’m mired in the “hygiene or fitness” forms of inherited technical debt, and many of the problems of knowledge loss that entails—I’m especially disappointed that most of the focus is on how to manage and make decisions around adding technical debt. It’s framed like extant technical debt is just a foregone, effectively permanent, conclusion. All of the same classification applies even if the debt (whichever metaphor applies) is already accrued and the consequences are already in full force.
Again probably because I’m mired in inherited tech debt, I don’t see any point in sharing this with my team because we already have a pretty good process for evaluating the risks and benefits of adding debt. But we (like most orgs IME) already have trouble responding to historical facts which present the same challenges as proposed future facts. I want this article to be addressed to “so you’re trying to manage tech debt you didn’t ask for.” And maybe I should just try to write that article, but I only have a glimpse of the conclusion myself and I’m loathe to add more setup without delivery to that particular aspect of the conversation.
At times, it can be advantageous to take on some amount of financial debt. For instance, you might be able to pay for a car with all cash, but if interest rates are low and you want to retain a healthy emergency fund, you might decide that it's more valuable to take on a loan.
But any auto loan you take on will have a repayment schedule that you have to agree to up front. And that is exactly how you should treat technical debt as well. You should figure out a term and a repayment plan, then get your stakeholders to commit to it.
Easier said than done, of course. But too often we label something as technical debt and it ends up at the bottom of a Jira backlog, and it's still sitting there years later.
cross-cutting concerns that are left to fixed later can leave you in a really bad spot (i.e. making revenue off the MVP, but largely unable to move it forward)
I couldn't go over all the weird ways it can go wrong in a comment (probably not even in a book), so I used "risk" as the catch-all umbrella, but yes, architectural bugs are a lot harder to fix. It's doable, but very tricky to pull off right.
