Every engineer has said it. A shortcut goes into the codebase under deadline pressure, someone flags it in code review, and the response is some version of "we'll fix it later." It gets said with total sincerity. Almost nobody who says it is lying.
The problem isn't the intention. The problem is that "later" has no owner, no deadline, and no line item in anyone's budget, which makes it functionally identical to "never" the moment the next deadline shows up and competes for the same attention.
The Sentence That Never Gets Revisited
Search any mature codebase for // TODO: fix this properly or # temporary hack, revisit soon and you'll find comments that are, in some cases, years old. Nobody set out to leave them there permanently. Each one represents a real moment where someone genuinely intended to come back, and each one got quietly outcompeted by the next sprint's priorities.
This isn't a discipline problem specific to any one team. It's what happens when a commitment has no tracking mechanism attached to it. A promise made in a code comment competes against a promise made in a sprint planning ticket, and the ticket wins every time because it's the thing that shows up on a board someone actually looks at.
Why the Cost Compounds Instead of Staying Flat
A shortcut taken once has a fixed cost: the extra care needed to work around it. A shortcut left in place for a year has a compounding cost, because every new feature built near it inherits the same fragility, and every new engineer who touches that area has to independently discover the workaround nobody documented.
That compounding is what makes "we'll fix it later" categorically worse than "we're accepting this cost and moving on." At least an explicit acceptance decision gets revisited when circumstances change. An implicit "later" just accumulates interest silently until someone hits it during an incident.
The Difference Between Deferring and Deciding
There's a real difference between a team that consciously decides to defer a fix, with the reasoning written down and a rough date attached, and a team that just lets "later" hang in the air unresolved. The first is a legitimate prioritization call. The second is how debt turns invisible.
Martin Fowler's writing on technical debt draws exactly this distinction, treating debt as a legitimate engineering tool when it's taken on deliberately and tracked, and a liability when it's taken on carelessly with no plan to address it. The difference isn't whether debt exists. It's whether anyone can point to the decision that created it.
How This Shows Up in Code Review Specifically
Code review is where "we'll fix it later" gets said most often, and it's also the easiest place to fix the pattern. Instead of letting the phrase pass unchallenged, the reviewer's job is to ask one question: where is this tracked? If the answer is "it isn't, yet," that's the moment to create the ticket before approving the PR, not after.
This takes maybe thirty seconds per instance. It's the cheapest intervention available anywhere in this whole problem, and it's the one most teams skip because it feels like friction in the moment a PR is otherwise ready to merge.
Why Teams Resist Tracking Every Shortcut
The honest objection to this is that tracking every single shortcut creates backlog noise, dozens of low-priority tickets nobody will ever look at. That's a fair concern, and the answer isn't to track everything with equal weight. It's to require a one-line business-impact note at creation time, so low-stakes shortcuts get triaged out quickly and high-stakes ones don't get buried in the noise.
The IEEE Computer Society has published extensively on software maintainability metrics, and one consistent finding across that research is that the cost of tracking debt is dramatically lower than the cost of rediscovering it during an incident, even accounting for the overhead of maintaining a register nobody enjoys filling out.
The Cultural Shift That Actually Works
Teams that get this right replace "we'll fix it later" with a specific, smaller commitment: "this is tracked as [ticket], targeted for [quarter], and here's why it's not blocking right now." That sentence takes ten extra seconds to say and completely changes the trajectory of the shortcut, because it now has an owner and a place to live instead of just a hopeful intention.
It also changes the tone of the retro conversation six months later. Instead of "why didn't we ever fix that," the conversation becomes "should we move this up, given what we now know," which is a much more productive place to be having the discussion from.
A Small Experiment Worth Running
If you want to see how bad this actually is on your own codebase, try this for one sprint: every time someone says or types some version of "fix later," require a linked ticket before the PR merges, no exceptions, even for a one-line change. Most teams that try this are surprised by two things. First, how often the phrase gets said. Second, how many of those tickets never would have existed otherwise, because writing the ticket forces a moment of actually deciding whether the shortcut is worth tracking at all.
Some shortcuts turn out not to matter enough to track. That's a fine outcome too, it just means the decision got made consciously instead of by default.
What Happens When Nobody Enforces This
Teams without any tracking discipline tend to converge on the same failure pattern regardless of how skilled the individual engineers are. The codebase accumulates a layer of undocumented tribal knowledge, this function looks wrong but don't touch it, that endpoint has a weird retry behavior nobody's explained, this config value is set to an odd number for a reason lost to time. New hires spend months rediscovering knowledge that already existed and was simply never written down anywhere durable.
GitHub's own engineering blog has covered this exact failure mode from the inside, describing how undocumented shortcuts compound into onboarding friction long after the original engineers who understood the tradeoffs have moved to other teams or left the company entirely.
Why This Is Cheaper to Fix Than It Looks
Teams resist adding tracking discipline because it feels like process overhead layered onto already-busy engineers. In practice the actual time cost is small, creating a ticket takes under a minute, and the payoff compounds every time someone searches for context on a piece of fragile code instead of guessing or asking around. The cost of not doing this shows up later, diffusely, as slower onboarding and repeated rediscovery, which makes it easy to underestimate until you're the one paying it.
Where This Connects to the Bigger Business Risk Question
Not every deferred fix needs to become a formal business risk conversation. Most don't. But the ones that touch payment flows, authentication, or regulated data absolutely do, and "we'll fix it later" is exactly the phrase that lets those specific items slip through without ever reaching the people who should be weighing in.
We wrote a longer piece on how to tell when a piece of deferred work has actually crossed that threshold, with a concrete scoring approach for separating engineering annoyance from real business exposure, over at our guide on technical debt and business risk. It's worth a read the next time "we'll fix it later" gets said in a review and something in the back of your head isn't quite comfortable letting it go unrecorded.
The One-Sentence Takeaway
"We'll fix it later" isn't a plan, it's the absence of one. The fix isn't to stop saying it, shortcuts are sometimes the right call under real deadline pressure. The fix is making sure the sentence never gets said without a ticket, an owner, and a rough timeline attached to it in the same breath.
Top comments (0)