archetypes

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.

technologyteams·4 min read

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.

~4 min read
Hero image for Fixes That Fail

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

System diagram for Fixes That Fail
Diagram: Fixes That Fail

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

Donella Meadows - Thinking in Systems, ch. 5: System Traps

Wikipedia: System Archetypes

Authors & Books

Go to references

Relevant references for Fixes That Fail.