The True Costs of “Technical Debt”

By Glenn Thrope

The term “technical debt” suggests that, like financial debt, we can take out a “loan” to hasten the development of our product. Then, somewhere down the line, we’ll “pay back” that loan by actually doing the work we previously pushed back. Borrow a week of coding now, and then do that coding sometime in the indeterminate future – no problem.

Many in the startup community see technical debt as perfectly acceptable – indeed, even desirable. When building a product, the logic goes, it’s best to get some product, any product in front of customers, and worry about cleaning up the code later. While there is some merit to this idea, it’s critical that entrepreneurs fully appreciate the costs of technical debt. These costs go far beyond the simple “borrow now/pay later” notion the term suggests.

First, let’s establish exactly what we mean by the term “technical debt”: bad code. Code that is not organized logically, code that is completely unreadable, code that seems to run okay about 90% of the time – all of this messiness has been neatly swept into the box labeled “technical debt.” It’s worth pondering how entrepreneurs might treat technical debt differently if we called it what it really is.

From an engineering perspective, bad code can spell doom for a product. Like a building with an unstable foundation, a design mistake made early in a product’s lifecycle can ripple through all future development. New functionality becomes difficult to implement, the product may crash for inexplicable reasons, and the code may be nearly impossible to understand. In the end, the company may be forced to undertake a costly rewrite – which, for a startup with just 3 months of runway left, could mean it’s all over.

But perhaps even more acute is the impact that technical debt can have on the morale of an engineering team. In many ways, writing code is more art than science. A well-written program sings with its simplicity and readability, and this elegance is what draws many engineers to the profession in the first place. To force an engineer to work, instead, in crufty, wonky code is a good way to demoralize and, ultimately, lose that engineer. This becomes especially true as a team grows and new engineers are brought in. While poorly written code may be readable to the person who wrote it, it can be nearly impossible for anyone else to understand.

In the early stages of a startup, some degree of technical debt is acceptable. Companies are in a race against time, and writing beautiful code cannot be priority number one. At the same time, however, founders should never delude themselves about the steep costs of incurring technical debt. As soon as product-market-fit is achieved, the bar for acceptable code must go way up, and existing bad code must be cleaned up. To do otherwise is to risk crippling both the product and, worse yet, the entire engineering team.