Sometimes later genuinely does happen. A deadline is tight, something needs to ship, and you knowingly take a shortcut with a plan to come back to it.
That’s fine.
The problem is when “later” quietly turns into “never”.
Not every shortcut is bad
I don’t think technical debt is automatically a bad thing.
Sometimes the sensible decision is to do the quicker version.
Maybe there’s a launch date that can’t move. Maybe a feature needs validating before anyone spends days making it perfect. Maybe the budget just doesn’t justify a bigger solution yet.
That’s normal.
The danger starts when a temporary solution is treated like a finished one.
A quick workaround gets added.
Someone says they’ll tidy it up after launch.
Eight months later, everyone’s forgotten why it exists and another bit of code has been built on top of it.
Now nobody wants to touch it.
The code usually isn’t the worst bit
When people talk about technical debt, the conversation tends to focus on messy code.
But it can show up everywhere.
It can be a CMS field nobody understands.
A plugin that should have been replaced years ago.
A dependency everyone is scared to update.
A third-party integration held together by assumptions nobody documented.
A build process that only works if one particular person remembers the magic command.
None of these things are necessarily catastrophic on their own.
They just make every future change slightly harder.
And eventually all those “slightly harder” things start adding up.
Temporary fixes have a habit of becoming permanent
This is probably the bit I see most often.
Something gets built quickly because it’s only temporary.
Then it works.
And because it works, nobody wants to spend time replacing it.
Which I understand.
If you’ve got a list of features the client actually wants, it’s difficult to justify spending a day rewriting something they can’t see.
Until that temporary fix starts causing problems somewhere else.
Then suddenly the work costs more, takes longer, and carries more risk than it would have if it had been dealt with earlier.
That’s usually how technical debt gets expensive.
Not because one bad decision destroys a project, but because lots of small compromises start relying on each other.
Context disappears faster than you think
A weird bit of code makes perfect sense when you wrote it:
- You know the third-party API had a bug.
- You know the client had a very specific requirement.
- You know the obvious solution didn’t work because of something buried in the existing system.
Come back a year later and it just looks bizarre.
Even worse if someone else has to work on it.
That’s why a small comment, a ticket, or a bit of documentation can save a ridiculous amount of time later.
Not every line of code needs an essay explaining it.
But if you’ve done something unusual for a reason, future you probably wants to know what that reason was.
“We’ll come back to it” needs an actual plan
This is probably the difference between manageable technical debt and technical debt that gets out of control.
If you knowingly take on debt, track it.
Put it in the backlog.
Leave a comment.
Create a ticket.
Agree when it needs reviewing.
Anything is better than relying on everyone remembering.
Because they won’t.
Not through laziness. Projects move on. People leave. Priorities change. New work arrives.
If the only record of a problem is somebody saying “we should fix that at some point”, it probably isn’t getting fixed.
Sometimes the right decision is still to leave it alone
There’s another side to this though.
Not every bit of technical debt needs fixing.
If something is ugly but stable, rarely touched and causing no problems, rewriting it just because it annoys you probably isn’t the best use of anyone’s time.
I think this is where experience matters.
You need to be able to look at something and ask:
Is this actually causing risk?
Is it slowing development down?
Is it making updates harder?
Is it going to become a bigger problem soon?
Or do I just not like it?
Those are very different things.
Technical leadership is partly knowing what to leave behind
It’s easy to look at a codebase and spot things you’d personally do differently.
That doesn’t mean they all need changing.
Good technical decisions aren’t always about making everything perfect.
Sometimes it’s about deciding where the team should spend its time, what creates genuine risk, and what can safely wait.
And if something does have to wait, making sure “later” means something a bit more concrete than “hopefully someone remembers”.
The expensive part is usually the delay
Technical debt rarely arrives with a giant warning sign.
It builds quietly.
One workaround.
One outdated dependency.
One undocumented decision.
One thing everyone knows is a bit dodgy but nobody has time to touch.
Then eventually a small change turns into a much bigger job because you’re not just building the new thing anymore.
You’re working around every old decision underneath it too.
Sometimes “we’ll fix it later” is exactly the right call.
Just make sure later actually exists.
