A codebase without tech debt is a dead, useless codebase. That sounds bombastic but is true in my experience. Every living, growing codebase I’ve worked on has some measure of tech debt.
A greenfield project is exciting — no tech debt to weigh you down! Freedom to innovate! It also does nothing and provides zero value in that state until you pour on the sweat and build something.
Then the requirements change and you’ve got to rush a feature to market. And the the product needs to scale and so you patch in some performance fixes quickly. And some 3rd party dependency didn’t work out like you thought it would and this pattern doesn’t scale as the complexity mounts. That database schema didn’t account for some business rule you discovered was important a year in and the queries become painfully slow.
But for all its warts, that is now codebase that delivers value to its end users—tech debt and all.
Tech debt is a sign of use just like a pile of dishes is a sign of a good meal shared.
The point is what you do after you find yourself in that situation, and what you’ve done to prepare.
Here are a couple points to prepare for the inevitable accumulation of tech debt in the process of building useful software. Follow established patterns.
Separating concerns in your application will allow you to change and swap pieces far easier.
You can incrementally evolve your codebase without doing a total rewrite.
Leave documentation about why things are the way they are.
It’s far easier to change something if you know it’s purpose in the system, not just what it does.
Cover yourself with tests that are decoupled from production code.
You can change things courageously if you have assurance that things will still work after you’ve refactored. But keeping your tests decoupled is important or you won’t be able to change either your source code or tests—and the tests are just another source of tech debt.
Plan time to address tech debt.
A good rule of thumb is to fix the tech debt the next time you are in that area of the codebase.
Like monetary debts, tech debt allowed you to get something you want now without paying the full sum up front. Just make sure you don’t default on those loans. Plan to pay them back slowly, week by week, and you’ll keep building valuable software.
So, at the end of the day, I’d prefer to ship software to real users than have no tech debt.