Tech debt, for lack of a better term, is good

“We don’t want to create any tech debt.”

This was the answer to me asking if we’d shipped a feature yet. What they meant by that statement was that they didn’t want to make a mistake; they didn’t want to build the thing that engineers spend the next five years complaining about.

But I would argue a different mistake was made. The mistake of not shipping fast enough.

Disclaimer: Every software platform has tech debt. It is an unavoidable reality. It is the side effect of taking small bets and learning as you go. For any technology organization, it’s not a question of whether you have tech debt, but of how you manage it.

Tech debt is the result of a tradeoff. We choose the quick and sometimes not fully baked way to ship something so we get customer feedback and iterate. As a startup we need to take risks and put features out there to see which ones resonate and which ones have no value. Looking back over a few years at a growing startup, many, if not most features, will no longer exist. There is no reason to take loads of time building a thing we will most likely throw away later.

No one would deliberately ship tech debt. Tech debt is the result of making technical tradeoffs that bite us later. They bite us because the solutions become too difficult to scale or maintain. This is a good thing. If you build a feature that ends up bringing us $10M in marginal revenue, we can hire a team to rebuild it.

Tech debt is not the enemy. The real enemy is tech overspending. The more common term in our industry is premature optimization. Don’t spend a year building something exactly the right way to solve a particular problem. None of us are smart enough to predict the future and we’ll end up throwing away the one-year build as fast as we throw away the one-month build.

Tech debt does not start out bad, but it does become bad. The pain points will become obvious. Don’t ignore the pain. Don’t adopt an attitude of learned helplessness. As engineers we need to be proactive about identifying the most impactful changes to our software systems, and work those upgrades into our prioritization process.

Same as financial debt, not all tech debt is bad. We are software engineers, not programmers, which means that it’s our job to make tradeoffs. And if you’re a startup focused on product adoption, you need to be willing to take risks to bring your product to market.

If you want to move fast with Opto, check out our careers page.

For disclaimers, visit https://www.optoinvest.com/disclaimers.