'I’ll refactor this later': The lie that ships with every sprint

There’s a moment in nearly every development task where you hit a small decision:

• Do I clean this up now?
• Or do I just get it working and promise myself I’ll come back to it? 🤞🏻

The second option always feels easier. More efficient. Responsible, even: “I’m not skipping it forever, just for now.”

But I’ll let you in on a secret that you won’t like: “I’ll refactor this later” is just “temporary” in business casual.

What we really mean when we say it

We don’t say it because we’re lazy. We say it because we’re under pressure. Deadlines are tight. Test cases are half-written. Someone’s waiting for this component. The PR already has 27 comments.

So we choose to make the thing work, and tell ourselves we’ll tidy it up when there’s time. But time never comes back around. And the next time this function gets touched, the person working on it has no idea why the logic is split and there is a TODO comment referencing an old Jira ticket.

Refactoring later isn’t a decision; it’s a delay with interest.

The emotional debt of unfinished cleanup

Unlike bugs or broken tests, this kind of debt doesn’t throw alarms. It just slows us down, silently. Every bit of unclear logic, every reused variable name, every shortcut we meant to fix: it all adds to the mental friction of working in that codebase. You stop trusting functions. You start working around things. You duplicate instead of reusing. And slowly, delivery speed drops.

We don’t notice the cost until it’s too late; until someone says the words we all dread:

“Should we just rewrite this?”

The decision to delay cleanup turns into a silent tax that compounds over time. It becomes harder to add features. Harder to test. Harder to onboard new teammates. We build tools to work around complexity we created ourselves. And worst of all? The code starts to feel hostile. You avoid touching certain files. You write messages that start with “sorry for this question…” You start dreading the next release.

When later doesn’t come

Yes, it rarely does. Even when we create tickets for cleanup, they sit in backlog purgatory. Technical debt doesn’t scream. Features do (or your PM). And unless you have strong engineering culture, proactive refactoring doesn’t happen by default.

• Teams change
• Context gets lost
• Priorities shift

The person who wrote the code may never come back to it. And if they do, it’ll be six projects later, with no memory of what they meant to refactor. In practice, “later” becomes a black hole. Anything sent there is gone for good unless a heroic effort drags it back into the light.

The Jira ticket myth

Sometimes, to feel better, we create a “Refactor XYZ later” issue in Jira. At best, this is documentation of intent. At worst, it’s a digital guilt trap that no one will open again. If your definition of done requires you to create a follow-up ticket for every refactoring you skip, ask yourself: How often do those tickets actually get picked up?

Do they live in a “Tech Debt” column that’s never part of sprint planning? Are they invisible to the product owner? Are they always at the bottom of every grooming session? If the answer is “almost never”, then the ticket isn’t a fix. It’s a way to feel like you’ve done the responsible thing, without actually doing it.

Refactor tickets are only useful if:

• They’re prioritized like real work
• They’re short-lived
• They have enough context to be actionable later

If not, they’re just the long-form version of “I’ll refactor this later”. Worse, they give teams a false sense of closure. The real work hasn’t been done. But it’s been moved. Abstracted away. And eventually forgotten.

Real cleanup isn’t heroic; it’s incremental

“I’ll refactor this later” is seductive because it feels pragmatic. But truly sustainable teams do the opposite: they refactor as they go, in small, low-risk steps.

That doesn’t mean polishing everything. It means for example:

• Renaming variables, functions, or classes so they express intent more clearly
• Extracting logic into smaller functions to make code easier to read and reuse
• Inlining unnecessary abstractions when they add no value
• Eliminating duplication
• Removing dead code and collapsing over-engineered conditionals
• Writing a small test before making a change so that the safety net exists—even if retrofitted

You don’t need a big refactor week. You need a culture where small, continuous improvements are normal. A culture that rewards care, not just output. And this culture doesn’t come from tools or templates, but from how teams talk about quality. It comes from leaders making space for cleanup. From reviews that notice and encourage thoughtful structure.

Shipping clean-ish code

Clean code isn’t a goal; it’s a habit. And habits don’t form around vague future promises. They form in the moment you almost say “later”… and then fix it anyway. It’s not about perfection. It’s about reducing friction. It’s about building code you can come back to, not with fear, but with confidence.

You don’t need to refactor everything. You just need to stop lying to yourself.

Leave it better than you found it. And don’t let “later” mean not never.