There are a few phrases in IT that sound entirely reasonable in the moment and carry significant risk over time. "We'll fix it later" is among the most common — and among the most consistently underestimated. It is not said carelessly. It is said under genuine pressure, in situations where it often represents the correct immediate decision. The problem is what happens — and more often, what does not happen — afterwards.
How It Starts
The context is almost always legitimate. Time pressure. Budget constraints. A delivery deadline that cannot move. A compromise is made — a shortcut, a workaround, a simplified implementation — with a clear and genuine intention to return to it properly when circumstances allow.
In one programme, we needed to deliver a key capability under significant time pressure. The architecturally correct solution would have taken longer than the timeline allowed. So we simplified the implementation, deferred some improvements, and accepted a degree of technical debt that we documented and intended to address in the following phase. At the time, it was the correct decision — a reasonable trade-off between delivery and completeness.
What did not happen was the follow-up. New priorities emerged. Resources were reallocated. The team that had built the simplified solution moved on to other work. The documentation of the debt existed; the plan to address it did not survive the next programme cycle. "Later" never arrived.
There is an old saying that has outlasted most management frameworks: "There is nothing more permanent than a temporary solution." It endures because it names something every generation of practitioners rediscovers. The people who first observed it were not being cynical about intentions. They were describing a structural reality of how complex systems evolve.
The decision to defer was sound. The assumption that deferral would be followed by resolution was not — because "later" is always in competition with the next deadline, the next priority, and the next problem that has arrived to claim the available capacity.
How Deferred Decisions Accumulate
The individual compromise is rarely the problem. The accumulation of many individual compromises, each reasonable in isolation, each deferred with genuine intent, is what creates the conditions that eventually make programmes expensive, risky, and slow.
The dynamic is compounding in the same way that financial debt compounds. Deferred technical debt does not stay at its original size — it grows, as the systems built around it become more dependent on it, as the original knowledge of why it was built that way erodes, and as the disruption required to address it increases with the passage of time.
The issue is not making compromises. Compromises are necessary in every programme of any scale. The issue is treating them as genuinely temporary when, in a large proportion of cases, they will become permanent.
Why "Later" So Rarely Comes
The specific failure of "we'll fix it later" is not a failure of intent. In my experience, the people who make these decisions genuinely intend to return to them. The failure is structural: "later" is perpetually crowded out.
Every organisation has more things it should do than capacity to do them. Remediation of known technical debt competes with new development, new regulatory requirements, new business priorities. In that competition, the known debt item — stable, not currently causing a visible problem — almost always loses to the urgent new requirement. The debt that was deferred "for a few months" is still there three years later, not because anyone forgot it, but because it was always lower priority than whatever else was demanding attention.
The Questions That Change the Decision
I still make pragmatic decisions to defer work when the circumstances genuinely warrant it. The discipline I have developed is to make those decisions with more deliberate honesty about what "later" actually means in the specific context.
That last question is the one that matters most. A deferral that produces something you could permanently live with is a reasonable design decision. A deferral that produces something you know will eventually require significant remediation is a debt — and it should be recognised, named, and owned as such from the moment it is created.
"We'll fix it later" is not a plan. It is a hope — and in complex technology environments, hope is rarely a reliable delivery mechanism.
The compromises are necessary. The honesty about what they create is equally necessary. Calling a permanent decision temporary does not change its consequences — it simply delays the moment when those consequences have to be faced, and usually increases the cost of facing them.