Accruing Technical Debt in Startups: Leverage or Road to Hell?

21 Nov, 2020

4 min read

Let’s start with a definition of technical debt just in case you have not heard this term before. You can find quite a number of wordings on the web; I personally like the one by Software Engineering Institute at Carnegie Mellon University: “Technical debt conceptualizes the trade-off between the short-term benefit of rapid delivery and long-term value”.

Technical debt has been a controversial topic since Ward Cunningham coined the term itself. Trading off technical design and/or engineering quality might sound as heresy to seasoned developers with strong engineering background. This is somewhat natural for at least two reasons: first, many software engineering books and publications strongly advocate against cutting corners and making shortcuts, depicting “code smells” and “design anti-patterns” as literally programmers’ deadly sins. Second, many of us ourselves have been through painful experiences, supporting and enhancing projects with tons of legacy code and poor maintainability.

So are there cases where cutting corners and making shortcuts would be justifiable? Or shall we rather consider technical debt absolute evil one has to avoid at all costs? The answer, indeed, depends on whom you ask.In the world of corporate systems with long shelf lives and reasonable amount of up-front planning, it would be hard to justify technical debt except for urgent business critical hotfixes.

However, startups live in a completely different world, and one really has to understand “the rules of the game” before making any conclusions. For a startup at its earliest stages, validating the business idea within the available budget and time constraints is a question of life and death. It’s a cruel world, really: if the startup runs out of money or misses an opportunity window without a working MVP, game over.
Now, where does this take us in terms of technical debt? Simple: throughout the relatively short period from formation to MVP, accrued technical debt rarely has any significant impact on product quality and development speed.

If we look at the design stamina hypothesis coined by Martin Fowler, early stage startups typically go under the design payoff line at least until they have started gaining considerable traction. There is even a high chance of “writing off” portions of the accrued debt if a certain feature gets negative market feedback and hence the development team totally discards the feature’s source code. This effectively enables startups to leverage technical debt as a tool to ship faster and experiment in the process.

What about the payday, though? Surprisingly, this is where the financial analogy becomes a bit stretched. With real monetary debt, you always have to pay it back including interest, or else you file for bankruptcy. With technical debt, though, your options could be much better than that.

Some technical debt, as I mentioned earlier, one can just painlessly write off while removing no longer needed functionality or pivoting. Some parts of the accrued debt, even though one cannot write them off completely, can have zero interest rate for the foreseeable future. In technical terms this means code that serves its purpose and does not need any significant modifications that could be negatively affected by the accumulated design trade-offs and/or maintainability issues.Finally, even the “normal” technical debt can have rather sparing interest rate as long as you stay under the design payoff line.

Still, even under these relaxed conditions, one should remember that blissful ignorance and dreaming about being able to accrue technical debt indefinitely is a recipe for failure. The design payoff line will hit you eventually, and you had better be prepared. I would recommend sticking to these principles, if I may:

Always try to avoid reckless technical debt. Shortcuts and tradeoffs should come from calculated risks and be justified by business decisions.
If you have to accrue technical debt with high interest rate (read: ugly hack made on the night before an important demo to potential investors), try your best to repay it as soon as possible. While many kind of technical debt are more or less harmless for early stage startups, it is still possible to shoot yourself in the foot when going overboard with quick and dirty decisions.
Carefully keep a track record of all the accrued debt. Like in finance, it’s all about accuracy and discipline. It is only so much debt you can accrue to stay under the design payoff line.

To conclude with a one-line summary: accrue responsibly 🙂 This will definitely do your startup more good than harm.