Why I've changed my mind about technical debt

Summer is always a busy time, but this year it seems especially so.

We had a total solar eclipse last week and my winery was in the path of totality. We had a nice group of friends out here to watch it (and, of course, drink far too much wine). It was a truly memorable experience — both the eclipse itself and the time spent with amazing people. I'll include a photo I took below!

If you follow the wine world at all, you may be aware that harvest is happening earlier and earlier every year as the summers continue to get hotter. We'll start picking our white grapes (Garnatxa Blanca for our young wine, Mauka) tomorrow. The earliest ever. Harvest time is a bit romantic, but it's also hard work under the hot summer sun.

Luckily, most of the other work I do can be done in air conditioning!

I am writing this (in air conditioning) to walk back a controversial statement I have made for many years.

If you've worked with me on an engineering team, you've probably heard me say:

Technical debt is not bad.

Let me explain.

Most of the engineering work I have done in my career has been focused on building startups or brand new software products. In these early stages, the goal is not architectural perfection; the goal is getting new features in front of users and learning quickly enough to survive.

Most new software products struggle early on (or fail completely). No one wants to admit that and no one thinks it will happen to them, but this is the reality we face every day. We need to make decisions that keep our costs down until we know we have a winning product.

When you're building an MVP or a new startup, your most costly resource is time. You pay for time (literally) with people's salaries and with infrastructure costs, but also with opportunity cost — if someone else beats you to market, it can be very expensive to reclaim lost territory.

I often advocate for engineering teams to make tough decisions in the interest of speed. Most engineers have an innate desire to build a perfect, robust, scalable, and flexible solution. They are proud of the elegance of that work.

But the economics of building new products often mean making sacrifices.

Perfect is the enemy of good.

Scalability is probably the easiest way to understand this. We know that (most likely) during the first few months of a new product's existence, we will not have to handle 10,000 concurrent users. We probably don't even have to handle 1,000.

The best kind of technical debt is intentional. If we know that an architectural decision we make while building a brand new product will create a scalability or performance bottleneck when we have thousands of users but it saves us weeks in development time, we will often take that chance.

This might eventually lead to some problems, but only if the product is successful. And if the product does become successful, then that's a good problem to have.

Another way of looking at this is understanding that most software products go through a lot of churn in their early stages. Why would you spend two or three times as much time to build something perfect when, in 6 months, you may realize that your target audience wants something different than you imagined and you have to scrap all that work anyway?

This also leads to the sunk-cost fallacy — it's a whole lot harder to throw something away, even if that is the right decision, if you know you invested a ton of time, money, or energy into building it.

Now that I've spent all this time convincing you that technical debt is not bad, let me explain why I am changing my tune.

One of our most expensive resources just got a helluva lot cheaper.

AI changes the economics. If engineering time becomes cheaper and faster, some shortcuts that used to make sense become less defensible.

In many cases, the most valuable time a senior engineer spends is designing platform architecture. Once these design decisions have been made, writing the code becomes a tedious implementation task — one that can increasingly be done by AI in far less time.

If we can make architectural decisions that allow products to be more scalable, more performant, and more robust and not cost additional development time, why wouldn't we do that?

When writing code to implement a design becomes a commodity, the engineering tasks that used to take us several weeks can now be done in a fraction of the time.

However, this brave new world is not without caveats.

Used improperly by the inexperienced and non-technical, AI can actually make your tech debt problem worse. It uses your existing architecture as context — if you're building with AI on top of a codebase that already contains poor patterns, AI will treat that as precedent, repeating the same mistakes. This can cause technical debt to compound quickly.

Technical debt is not necessarily bad, but unintentional technical debt is. And AI makes it much easier to create a lot of it very quickly.

Cheers,

Ryan

PS. This email is long enough already but I would regret not mentioning that one of our Foundry products, Cut Club, has really taken off over the last couple of weeks! If you're looking for a game to play with your team, give it a try!

PPS. As promised, here is a photo I took of the eclipse last week.