There's a whiteboard in the back of my memory that I can't quite erase. It belongs to a startup I visited in 2019 — a fintech outfit in a converted warehouse in Austin, the kind of place with exposed ductwork and a ping-pong table nobody used. Their CTO, a compact, fast-talking woman named Priya, was explaining to a room of nervous investors why the product had shipped six weeks ahead of schedule. On that whiteboard, in red marker, were two columns. One said Clean. The other said Done. She tapped the second column and said, simply, "We chose done."
I thought about that whiteboard for years afterward. At the time I filed it under "pragmatism," which is the polite word engineers use when they want to say "we cut corners and it worked out." But the longer I've spent watching software teams build things — and watching other software teams spend eighteen months refactoring things that already worked — the more I think Priya was pointing at something more fundamental than a scheduling trick. She was describing a philosophy. And it's a philosophy the industry has been too embarrassed to defend out loud.
So let me defend it.
The Loan Metaphor Was Always Incomplete
Ward Cunningham coined the debt metaphor in 1992, and it was a good metaphor for its moment. He wanted a way to explain to non-technical managers why code that worked today might cost more to change tomorrow. Debt, with its connotations of interest payments and compounding risk, did that job efficiently. The metaphor spread, mutated, and eventually became the dominant frame through which the entire industry talks about imperfect code.
But here's what the metaphor left out: debt, in the financial world, is not inherently bad. It is a tool. Mortgage debt lets a family live in a house while they pay for it. Business debt lets a company capture an opportunity that would evaporate if they waited to save up the cash. The question has never been whether to take on debt — it has always been whether the thing you're buying is worth the interest.
Somehow, in the translation from finance to software, that nuance got dropped. Tech debt became a synonym for failure, for sloppiness, for teams that didn't care enough to do it right. The shame attached itself to the metaphor and stayed there. And that shame, I'd argue, has cost the industry far more than any messy codebase ever did.
Speed Is a Feature, Not a Consolation Prize
I want to be precise about what I mean, because this argument gets misread. I am not saying that all technical shortcuts are equal, or that you should never refactor, or that a codebase maintained by people who have given up on themselves is somehow fine. It isn't. There is a version of tech debt that is genuinely ruinous — the kind that accumulates not from a deliberate tradeoff but from a team that never had a plan to pay it back, or from leadership that used "we'll clean it up later" as a permanent deferral strategy. That version deserves every ounce of its bad reputation.
What I'm talking about is the deliberate, conscious, documented choice to ship something imperfect because the cost of perfection exceeds the value of the delay.
Speed is a feature. Not in the glib sense that startups use it to excuse chaos, but in the precise sense that getting a working thing in front of real users earlier generates information that no amount of internal refinement can produce. Users are ruthless and honest in ways that code reviewers never are. They will tell you, with their behavior if not their words, whether the thing you built solves the problem you thought you were solving. And if it doesn't — if the whole premise was slightly wrong, as premises so often are — then the elegant architecture you spent six extra months building is not an asset. It is a sunk cost dressed in clean clothes.
Priya's company, incidentally, pivoted their core product eight months after that investor meeting. The code they shipped fast was thrown away. But because they'd shipped it fast, they had the runway — financial and temporal — to throw it away and try again. The companies that spent those same months polishing their first idea were still polishing it when the market moved.
What "Paying It Back" Actually Looks Like
The strongest objection to this argument is the one I take most seriously: that teams who embrace tech debt rarely pay it back. They ship the rough version, they move on to the next feature, and the rough version calcifies into the foundation of everything that comes after. Interest compounds. New engineers join, inherit the mess, and either leave or adapt to it. The codebase becomes a place where good instincts go to die.
This is true. It happens constantly. But I'd push back on the diagnosis. The problem in those cases isn't that the team took on debt. The problem is that they took on debt without a repayment plan, which is a management failure, not a philosophical one. The solution isn't to avoid debt. It's to treat it with the seriousness that financial debt demands: acknowledge it explicitly, schedule the work, and protect that schedule from the same product pressures that created the debt in the first place.
The teams I've seen do this well share a habit: they write down what they cut and why. Not in a ticket that gets closed and forgotten, but in a living document — sometimes embarrassingly simple, a shared note or a tagged backlog — that gets reviewed quarterly. They give the debt a name. Naming it makes it real in a way that vague guilt never does. "We shipped the payment flow without input validation because we had three days before the conference demo, and we will fix it in the sprint after launch" is a sentence that can be honored. "We have some tech debt" is a sentence that disappears into the air.
The Hidden Cost of Perfectionism
There is a failure mode that doesn't get nearly enough attention in engineering culture, and it is the failure mode of the team that never ships. I have watched talented engineers spend months designing systems of extraordinary elegance for problems that, by the time the system was ready, had either been solved by a competitor or turned out to be less important than originally believed. The code was beautiful. The opportunity was gone.
Perfectionism in software has the same psychological structure as perfectionism anywhere else: it is, at its root, a fear of judgment dressed up as a standard. If the code is never done, it can never be wrong. If the architecture is always being refined, the architect is always improving rather than failing. This is not a work ethic. It is a defense mechanism, and it is expensive.
Why tech debt is actually good, in the end, is the same reason that a rough draft is actually good: it exists. It can be read, criticized, improved, or discarded. A perfect document that was never written helps no one. A shipped product with messy internals can be used, loved, iterated on, and eventually cleaned up. The mess is not the point. The existence is.
Priya's whiteboard had it right. Done is not the enemy of clean. Done is the prerequisite for clean — because you can only refactor something that exists, and you can only know what's worth refactoring once you've watched real people use it.
The question worth sitting with isn't whether your codebase is perfect. It's whether the debt you're carrying is debt you chose, or debt that chose you.