Technical debt is defined as “a concept in software development that reflects the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer. As with monetary debt, if technical debt is not repaid, it can accumulate ‘interest’, making it harder to implement changes.”

In other words: because you don’t have enough time to do the right thing, you do a not-so-right thing that takes less effort; this will bring negative consequences in the future which you’ll spend time fixing.

From a purely economic perspective, the optimal solution to this problem is to measure the cost of implementing the feature (including the opportunity cost of not implementing other features or postponing the product launch) vs the cost of not implementing it (or implementing it badly).

In practice, this calculation is almost always very hard to perform, because of the non-linear nature of design decisions, and the sheer unpredictability of designing software that you haven’t designed before.

How do I make this decision? I try to always make decisions that will accrue no debt. Sometimes this means spending some more time. Most often, it requires rethinking and reducing the original scope, keeping it useful but making it more focused. Every once in a while, I’ll take on debt, but I will be sure to document it specifically and state exactly why this is a bad decision and why there’s no obvious way around it at the particular moment.

Technical debt is the death of a thousand cuts: the time you spend chasing after bugs in a system you don’t understand doesn’t make you grow and doesn’t make the system fundamentally better. Many software organizations spend the bulk of their human-hours fixing bad decisions, rather than making the good ones. This is exactly where I don’t want to end up.

When poised at the crossroads of a decision that could become technical debt, think: how can I get out of this elegantly? Usually, there’s a way.