Code Is Debt

> Clearly, the company with fewer lines of code is better off.

Fewer lines of code are better if functionality is constant. But that doesn’t make code debt. By that logic, factories, employees, equipment, processes, and policies would also be debt — since fewer of them would likewise be better if revenue stayed constant.

Code is fundamentally an asset: it generates revenue, scales with near-zero marginal cost, and embodies intellectual property. Like any asset, it carries liabilities. Well-designed and reliable code behaves like a productive factory; buggy or hard-to-maintain code behaves like debt, draining resources instead of producing returns.

Exactly, this blog post is grossly oversimplifying, and maybe we are meant to “get the idea” but I think that even if it’s intentionally oversimplified it needs to address the elephants in the room.

Is longer code more “debt” if it’s more readable and more verbose? I could save lines of code by messing ternary operators, shortening variable names, using obscure language-specific features, or stuffing complicated expressions into one-liners.

Is longer code more “debt” if it’s more extensible and flexible for future growth and change?

Is longer code more “debt” if it has more test coverage? This is especially relevant to the article because AI is generally great at assisting with writing tests especially when the alternative is engineers not doing it.

We can’t just say “all else being equal” because that’s not how life works.