Anti-Pattern Catalog¶
Remediation catalog — instantiates Archetype Pattern Indexing
Indexes recurring structures that reliably go wrong, pairing each with the near-misses that are actually fine and the remediation that follows once a match is confirmed.
An Anti-Pattern Catalog indexes recurring structures that look like reasonable choices but reliably produce bad outcomes — each entry a named trap paired with the remediation that gets you out of it. Its defining move is inversion: where a reuse catalog says "reach for this," an anti-pattern catalog says "you are probably already doing this, and here is how to stop." Because the whole purpose is warning rather than adoption, its center of gravity is the guard against false alarms — the near-misses that resemble the trap but are legitimate — and the fix a confirmed match licenses. It does not lead with an abstracted structural signature the way a design catalog does; it leads with recognition-under-suspicion and a way out.
Example¶
A program office at a manufacturer keeps an anti-pattern catalog of recurring project failures. One entry is Death March — a project everyone privately knows cannot hit its date but that marches on anyway. The card names the tell-tales (slips quietly absorbed by overtime, a risk register that has stopped moving, nobody empowered to change the date), then a near-miss column of cases that look identical but are not a Death March (a genuinely aggressive sprint that is fully resourced and has an owner who can still renegotiate scope). Finally it gives the remediation: re-baseline, cut to a defensible core, or kill — and explicitly lists "just add people" under the moves that make it worse.
A program manager three weeks into a troubled rollout recognizes four of five tell-tales. She checks the near-miss column, finds none of the exculpating conditions hold, and flags the project at medium-high confidence for a re-baseline review rather than reaching reflexively for more headcount. The catalog turned a vague dread into a named, confidence-tagged call with a prescribed next move — and stopped the instinctive fix that the same entry warns against.
How it works¶
Each entry is a solution structure recorded as a warning. The signature is present only implicitly, framed as symptoms of the trap; the substance lives in three places. First, a near-miss column — the legitimate look-alikes and the conditions that exempt them — because the dominant failure of any warning catalog is over-diagnosis, and the counterexamples are what keep a merely hard case from being branded a mistake. Second, a remediation paired with each trap, so the catalog prescribes an exit rather than just assigning blame. Third, a confidence or severity band on any flag, so a match reads as a provisional suspicion, not a verdict. Retrieval into the catalog is by symptom, but the catalog itself borrows its search facets from a Tagging Schema rather than defining them.
Tuning parameters¶
- Severity vs. remediation cost — how drastic a fix each trap prescribes. Reserve the expensive remediations (re-baseline, kill) for high-severity entries; cheap nudges for the rest.
- False-positive tolerance — how much evidence is required before a flag is raised. A tight bar reduces alarm fatigue but lets some traps run; a loose bar catches more but erodes trust in the catalog.
- Counterexample richness — how many exempting conditions each entry carries. More near-misses guard harder against over-matching but take real authoring effort.
- Confidence banding — coarse (flag / no-flag) versus graded severity. Graded bands preserve nuance; coarse ones are faster to act on.
When it helps, and when it misleads¶
Its strength is naming failures that people are living inside and therefore cannot see — and, crucially, granting permission to stop, because a well-authored anti-pattern comes with a sanctioned exit.
Its failure mode is anti-pattern zealotry: once every difficulty has a scary name, the catalog becomes a cynicism engine and every hard project gets branded a Big Ball of Mud[1] or a Death March on thin evidence. The classic misuse is running it backwards — reaching for an entry to indict a project after the fact rather than to remediate one in flight. The guarding discipline is to require the near-miss check before any flag is raised, and to refuse to publish a warning without a paired remediation: a trap with no way out is not a pattern, it is an accusation.
How it implements the components¶
counterexample_set— the near-miss column of legitimate look-alikes is the catalog's primary guardrail against over-diagnosis; it is what separates a real trap from a merely hard case.response_guidance— every confirmed anti-pattern ships with a remediation (the "refactored solution"), so recognition converts directly into an exit move.confidence_label— each flag carries a severity-and-certainty band, keeping a match provisional rather than treating a scary name as proof.
It distills no pattern_signature, curates no exemplary example_set, and draws no neighbor_distinction map — those positive-reuse roles belong to its nearest twin, Design Pattern Catalog: a design catalog indexes structures to adopt, an anti-pattern catalog indexes structures to escape.
Related¶
- Instantiates: Archetype Pattern Indexing — it supplies the warning-and-remediation side of the index, the entries you retrieve to recognize what has already gone wrong.
- Consumes: Pattern Card Template gives each entry its fixed slots; Tagging Schema supplies the symptom facets it is searched by.
- Sibling mechanisms: Design Pattern Catalog · Case Library · Diagnostic Atlas · System Archetype Index · Solution Archetype Archive · Pattern Card Template · Tagging Schema · Pattern Library (a catalog of approved exemplars to reuse — the positive mirror of this one).
Editorial Notes¶
Form Classification¶
Form family: Representation, Specification & Plan
Rationale: Indexes recurring structures that reliably go wrong, pairing each with the near-misses that are actually fine and the remediation that follows once a match is confirmed, making its operative form a non-executable information artifact that externalizes static or prospective structure.
Independent corroboration: The frozen evidence defines Anti-Pattern Catalog as 'Indexes recurring structures that reliably go wrong, pairing each with the near-misses that are actually fine and the remediation that follows once a match is confirmed', so its operative form is Representation, Specification & Plan.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Single lineage
Present-day reach: Multi-domain
Rationale: The named anti-pattern catalog was popularized in software architecture as a repertoire of recurrent bad solutions and refactorings.
Related originating lineages:
- Architecture & Urban Planning — The broader design-pattern tradition drew heavily from Christopher Alexander's pattern language.
- Engineering & Design — Failure catalogs and design heuristics provide parallel professional practice.
- Organizational & Management Science — Organizational anti-patterns extend the format to management structures.
Review resolution: Software engineering coined and popularized the anti-pattern catalogue. Architectural pattern language, engineering failure repertoires, and organizational learning are materially formative, but the named mechanism remains a single software lineage with transferable reach.
Review outcome: Reconciled after independent review; high confidence.
References¶
[1] The term anti-pattern was coined by Andrew Koenig (1995) and popularized by the AntiPatterns book (Brown, Malveau, McCormick & Mowbray, 1998), whose defining convention is to pair each recurring bad structure with a "refactored solution" — the remediation column this mechanism treats as mandatory. registry ↩