Fixes That Fail Diagnosis¶

Feedback-trap diagnosis — instantiates System Archetype Diagnosis

Diagnoses a problem that keeps relapsing as Fixes That Fail — a quick fix whose delayed side effect quietly recreates the very symptom it relieved.

Version: v1 · 2026-08-24 · History
Mechanism #: 3680
Type: Feedback Trap Diagnosis
Form family: Analysis, Modeling & Optimization
Solution family: Adaptation & Reconfiguration
Problem family: Representation, Classification & Model Misfit
Problem subfamily: Model Assumption, Regulation & Residual Refinement
Origin domain: Systems Thinking & Cybernetics
Also from: Organizational & Management Science
Instantiates: System Archetype Diagnosis

Fixes That Fail Diagnosis reads a problem that keeps coming back — always after the same "solution" was applied — as one specific feedback trap: a quick fix that relieves the symptom immediately, while a delayed, usually unintended side effect of that same fix erodes the situation and, after a lag long enough to hide the connection, regenerates the original symptom. Its one distinguishing idea is that the fix does not merely fail to last; the fix is the cause of the return. The diagnosis therefore centers on finding the lagged side-effect loop and on defining the signal that would catch the backfire in time, so the true cost of the quick fix — paid later, elsewhere — can be set against its immediate relief.

Example¶

A software team is paged for a production outage. Under pressure they ship a hotfix: a targeted workaround that silences the failing code path. The alert clears, the incident closes, everyone moves on. Three weeks later a different service falls over — and the on-call engineer, sketching the history, notices the pattern. Each hotfix has bolted a special case onto a shared module, and the accumulating tangle now makes each part more brittle than before. Fixes That Fail Diagnosis is the step that names this: the quick fix (a workaround) buys same-day relief, but its delayed side effect (rising coupling and fragility) reliably produces the next outage. The diagnosis does not just say "stop hotfixing." It identifies the specific thing to watch — a fragility signal such as the count of workarounds touching the shared module, tracked over the lag window — so the team can see the backfire building rather than rediscovering it at 3 a.m.

How it works¶

Separate the quick fix from the fundamental solution. Name what was actually done under pressure versus what would address the underlying cause.
Trace the delayed side-effect loop. Follow the fix forward past its immediate relief to the consequence that returns, later, as the same symptom.
Measure the lag. The delay is exactly why the connection is missed; putting a number on it is what makes the loop believable and monitorable.
Confirm the fix is the cause, not a coincidence. Check that the recurrences follow the fix rather than an unrelated new problem — the trap requires a genuine causal link, not correlation.

Tuning parameters¶

Delay window — how far ahead you look for the side effect. Too short and the backfire falls off the edge of the analysis; too long and unrelated events get blamed on the fix.
Fix / fundamental boundary — where you draw the line between symptomatic and root solutions. Drawn loosely, every action looks like a doomed fix.
Side-effect scope — how many downstream variables you trace. Wider scope catches indirect backfires; narrower keeps the causal story testable.
Recurrence threshold — how many relapses count as a pattern rather than bad luck. Set it too low and one-off failures masquerade as the trap.

When it helps, and when it misleads¶

Its strength is that it explains the maddening experience of a fix that "worked last time" and keeps failing, and it makes the deferred cost visible early — so a team can price the quick fix honestly instead of paying its interest in perpetuity.^[1] By naming the specific side-effect signal, it converts a vague dread of technical debt into something a dashboard can carry.

Its failure mode is diagnosing a fix-caused cycle where there are really two independent problems that merely happen to recur — mistaking correlation for the trap. The classic misuse is the opposite overreaction: treating every quick fix as forbidden, when a bounded fix with no eroding side effect is often exactly the right call. The guarding discipline is to require evidence for the fix→side-effect link before accepting the label, and to keep the monitoring signal honest — an informal check that the backfire is actually building — rather than assuming it because the story is tidy.

How it implements the components¶

symptom_pattern — collects the signature of this trap: relief followed by relapse, each episode preceded by the same fix, and a return that arrives on a delay.
archetype_match — names Fixes That Fail once a single fix with a delayed, symptom-regenerating side effect is established.
monitoring_signal — defines the leading indicator of the backfire (the accumulating side effect) so the delayed consequence can be caught while it is still building.

It does not prescribe the wean-off-and-rebuild response — that play, and the deepening dependence it addresses, is intervention_playbook in Shifting the Burden Diagnosis, the near-twin where the fix keeps working while the capacity for the real solution withers. Nor does it validate its own match: pattern_fit_evidence and counterexample_check belong to Archetype Fit Checklist.

Instantiates: System Archetype Diagnosis — supplies the delayed-backfire reading of a recurring problem.
Consumes: System Archetype Template supplies the stored Fixes That Fail pattern the situation is matched against.
Sibling mechanisms: Shifting the Burden Diagnosis · Escalation Archetype Mapping · Limits to Growth Diagnosis · Tragedy of the Commons Diagnosis · Archetype Fit Checklist · Leverage Point Matrix · Pattern Diagnosis Workshop · System Archetype Template · Causal Loop Diagram

Editorial Notes¶

Form Classification¶

Form family: Analysis, Modeling & Optimization

Rationale: Fixes That Fail Diagnosis operates as a computation, comparison, model, or analytic representation used to infer, estimate, or choose because it diagnoses a problem that keeps relapsing as Fixes That Fail — a quick fix whose delayed side effect quietly recreates the very symptom it relieved.

Independent corroboration: The frozen evidence defines Fixes That Fail Diagnosis as 'Diagnoses a problem that keeps relapsing as Fixes That Fail — a quick fix whose delayed side effect quietly recreates the very symptom it relieved', so its operative form is Analysis, Modeling & Optimization.

Review outcome: Independent reviewer agreement; high confidence.

Origin Attribution¶

Primary origin: Systems Thinking & Cybernetics

Origin pattern: Single lineage

Present-day reach: Universal

Rationale: Fixes That Fail is a named system-dynamics archetype describing delayed side effects that recreate symptoms.

Related originating lineages:

Organizational & Management Science — Management learning practice materially popularized archetype diagnosis in organizations.