Kids, it’s 2020. That means it is way past time to stop kicking the can down the road. Most of us in IT have been around long enough to see the industry shift from centralized (mainframe) to decentralized (client/server) architectures and back to centralized again (cloud). That means we have encountered problems, and we have ignored problems, and those ignored problems have a name. It’s called Technical Debt — and the check is coming due.
What Is Technical Debt?
Technical debt is the accumulated cost of taking shortcuts. Every “we’ll fix it later” that never got fixed, every quick patch on top of a broken design, every legacy process nobody wants to touch because nobody fully understands it anymore — that’s debt. Like financial debt, it accrues interest. The longer you ignore it, the more expensive it becomes to pay off.
We all have it. It tends to bite us right in the ass.
What It Looks Like in a SQL Server Environment
Debt looks different depending on where you sit, but in a SQL Server shop it usually shows up as:
- Heap tables — tables with no clustered index, left over from a decade-old import that “was just temporary”
- Missing or redundant indexes — tables with 30 indexes that nobody has audited since 2012, alongside critical tables with none
- Stored procedures nobody will touch — 3,000-line procs with no comments, dynamic SQL built by string concatenation, and a reputation for being cursed
- Hardcoded server names and file paths — because the environment was never designed to move
- No source control — database changes made directly in production, with no history of who changed what or why
The common thread: these things work, until they don’t. And when they don’t, they fail at the worst possible moment.
Why It Bites You
Technical debt isn’t just an engineering inconvenience. It slows down every new feature, because every change has to navigate the landmines left by previous ones. It increases on-call risk, because nobody fully understands the system. It drives good engineers out the door, because nobody wants to spend their career maintaining something that should have been rebuilt years ago.
Stop covering it up with more hardware, crazy monitoring schemes, and automated fixes that just treat the symptoms and ignore the underlying problems. Scaling up a server to mask a bad query is not a solution — it’s a more expensive way to delay the inevitable.
How to Start Paying It Down
You don’t need a six-month freeze and a full rewrite. Start small and be deliberate:
- Identify and document — you can’t prioritize what you haven’t named. Run
sys.dm_db_index_usage_stats, review query store data, and start a list. - Quantify the impact — not all debt is equal. Prioritize the items that cause the most incidents, slow the most queries, or block the most deployments.
- Allocate time — even 10-20% of each sprint dedicated to debt reduction compounds over time. Make it a standing line item, not a special project.
- Get things into source control — if it isn’t in source control, it doesn’t exist in a recoverable, auditable way.
- Stop adding new debt — code review, peer review, and a “done means documented” standard go a long way.
Just start working on it. You’ve known about this debt for years — maybe decades — and it is not going to get worked on by itself.
Key Takeaways
- Technical debt is compounding interest on every shortcut you’ve taken. The longer you wait, the more it costs.
- In SQL Server environments it shows up as heaps, bloated procs, missing indexes, and zero source control.
- Patching symptoms (more hardware, more monitoring) is not the same as paying down debt.
- Allocate time consistently — 10-20% per sprint — rather than waiting for a big rewrite that never happens.
- Your customers will thank you, your developers will thank you, and your staff will thank you.