Fixes That Fail
A quick remedy eases the acute symptom immediately, but it triggers hidden side effects that return in the medium or long term.
Why it matters
An archetype helps you recognize recurring dynamics behind local symptoms.
Next step
Next, move into a diagnostic method to test the suspected structure against observations.

Description
The archetype "Fixes That Fail" describes a common dynamic of technical debt. A problem appears, and under operational pressure a quick fix is applied. In the short term, the symptom disappears. The fast fix does not resolve the structural cause, however, and creates unintended long-term consequences. These side effects become visible only after a delay and can significantly worsen the original problem. The next quick fix is then often applied.
Feedback Loops
The system consists of a balancing loop and a problematic reinforcing loop. The balancing loop is the short-term solution: a symptom appears, the fix is applied, the symptom disappears. The reinforcing loop works with a delay: the same fix triggers a side effect that further intensifies the original problem.
Architecture Example
An in-memory database instance such as Redis regularly fails under load. The architecture team's quick fix is to add an auto-restart script and more aggressive health checks. The symptom seems gone because Redis becomes available again quickly after each failure. The delayed side effect is that the application actually has significant memory leaks. Because of the automatic restarts, the problem is initially less visible. Two months later the leak has grown, Redis fails more often, and caches are cleared regularly. The auto-restart delayed the structural solution: memory analysis and code repair.
Organizational Example
A project falls significantly behind schedule. Management adds more developers by pulling them from other teams. In the short term this calms the situation because more activity is visible. The problematic side effect is Brooks's Law: onboarding new people consumes significant time from existing developers. A few weeks later the project slows further, and the teams that gave up people also lose capacity.
Diagnostic Questions
1.Are we celebrating a solution as reactive even though we never truly understood the architecture behind it, basically practicing guesswork debugging?
2.For which regularly failing components is our only response to restart harder, add more servers, or raise the container memory limit?
3.Which legacy scripts and workarounds still barely solve an old problem, while creating an high operational burden for us today?
Diagram
How to Recognize the Pattern in Daily Work
What makes Fixes That Fail so deceptive is the human brain. Because the side effect appears after a delay, teams often no longer make a mental connection between the brilliant fix from three months ago and today's significant disaster. They treat the disaster as a new problem. Systems thinkers therefore enforce a culture of root-cause analysis. Quick fixes are acceptable in the emergency surgery of an incident, but a ticket is not truly closed until the operation, the root-cause refactoring, has been completed afterward.
What Distinguishes the Pattern from Similar Dynamics
Fixes That Fail resembles Shifting the Burden. The key difference is that in Fixes That Fail the fix itself causes a direct side effect in the same system. In Shifting the Burden, the quick fix primarily creates dependence on symptomatic treatment while the fundamental solution is neglected.
How to Move from Pattern to Response
Accept the need for quick fixes because operational systems sometimes need immediate stabilization. But document every such fix as explicit follow-on work, not only as technical debt. Every architecture decision that matches a Fixes That Fail pattern should create a prioritized story for the structural solution. If this root-cause work is permanently deprioritized, systemic risk grows.
First Next Steps
Use retrospectives to make delayed side effects visible after the fact. Ask directly: "Which earlier quick fix might have contributed to today's incident?"
How to Recognize the Pattern with Confidence
In high-severity incidents, do we clearly record the short-term mitigation and the structural remediation?
Sources
The Systems Thinker: Fixes That Fail
Authors & Books
Go to referencesRelevant references for Fixes That Fail.
Continue reading
Explore related topics from Archetypes
Accidental Adversaries
Teams that actually want to collaborate drive each other into ruin through selfish local optimizations.
Attractiveness Principle
A rising product or team attracts so much demand that quality collapses and the very source of its attractiveness gets damaged.