I keep hearing engineers blame tech debt for everything.
Bad deploy? Tech debt.
Slow feature? Tech debt.
Coffee machine broke? Definitely tech debt.
No. Most of the time, that's not debt. It's just a mess. Calling it debt is a nice way to avoid saying, "We made a choice, and it didn't work."
The term "tech debt" got stretched until it broke
I didn't hear the phrase "technical debt" until I was already writing production code at my third or fourth company. Before that, we just said stuff like "this is brittle" or "we're gonna regret this later."
I once spent six months writing custom BI software in C++ for AT&T. Not because they asked for it. Because I thought it would be cool.
I also wrote a custom encryption algorithm to pass database credentials between servers. Why? Because I could. Should I have? Absolutely freaking not.
Technically impressive? Sure.
Stupid? Completely.
An off-the-shelf enterprise BI tool would have done the job better, faster, and with less risk. That wasn't technical debt. That was me choosing fun engineering over sane engineering, and then handing the bill to future Sethers.
Real debt has paperwork. Lots of it.
Financial debt doesn't happen by accident. You don't accidentally get a mortgage.
You bring pay stubs. Tax returns. Bank statements. You sign things. You initial things. You sign things that say you signed the other things. It's a whole process designed to make sure everyone agrees on the deal.
Debt is a deliberate act. It has terms. It has interest. It has a paper trail.
So why do we act like technical debt is "any code I don't like"?
A narrower definition
Here's my working definition:
Technical debt is a deliberate shortcut taken to hit a near-term goal, with known future costs
That's it. If it doesn't meet that bar, I won't call it tech debt.
What technical debt is NOT
Technical debt is not:
- "This code is old"
- "This code is ugly"
- "We don't like the framework anymore" (Angular1... grr)
- "We rewrote the whole app and it still sucks"
How many times do teams scrap entire applications because they had too much tech debt, then rebuild the exact same problems in a new stack.
The real issues were usually:
- unclear requirements
- solving the wrong problem
- picking the wrong platform
- building for an imaginary customer
- ivory towers of knowledge where only one person knows how anything works
My process: make debt annoying to take on
When someone on my team wants to take a shortcut, here's what I make them do:
- Comment the code right where the shortcut lives.
- Update the README with the date.
- Write the payback plan with a real target date.
- Explain it to me like I'm the one who'll get paged at 2am when it breaks. Because that's happened before.
Engineers hate this. Good. If it's easy to take on debt, people take on too much of it.
The funny outcome: my teams take on less debt
Once people have to write the shortcut down, a bunch of shortcuts stop happening.
I don't know if it's the definition or the fact that engineers would rather write correct code than update documentation. Either way, it works.
Debt is fine. Lying about it isn't.
Startups are supposed to move fast. Taking shortcuts is fine, I strongly encourage shortcuts at startups.
Just stop calling every regret "technical debt." Keep the definition tight, document it as it happens, and make the interest visible.
If you can't explain the shortcut and how you'll pay it back, you didn't take on debt. You just made a mess and gave it a fancy name.
-Sethers
I use AI to generate images for my posts as well as editing,
update suggestions, internal link suggestions, and SEO
(hell yeah I do). I used to draw all of the illustrations
myself, but I really like how Flux2 interprets my ideas. If
you ever want to chat about my use of AI, hit me up.
Top comments (0)