Anti-Pattern Review¶
Catalog-based review — instantiates Archetype Overmatching Guardrail
Checks the case against a catalog of the archetype's known look-alikes — situations that show the surface markers but carry a disqualifying feature — so a familiar-looking failure isn't mistaken for the pattern it mimics.
Anti-Pattern Review works the guardrail from the failure side. It maintains a catalog of the archetype's known anti-patterns — cases that wear the pattern's surface badge but contain a structural disqualifier that makes applying the pattern actively harmful. The review separates the tempting surface markers (logged and explicitly discounted as non-probative) from the specific disqualifying features (tested for). Its defining move is that a hit on a catalogued disqualifier flips the label from pattern to anti-pattern — the resemblance was real, the fit was not.
Example¶
A team proposes a shared Singleton configuration object: "this is the classic case for a Singleton — one config for the whole app." An anti-pattern review pulls the catalog of Singleton anti-patterns. First it logs the surface markers that make Singleton tempting — there is conceptually one of the thing, and global access is convenient — and marks them non-probative, because they are exactly what fools people. Then it tests for the disqualifying features that turn Singleton into an anti-pattern here: does the "one" instance actually vary by tenant, test, or thread? Does global access hide dependencies and block testability? Both fire — the app is multi-tenant and the team already fakes the singleton in tests. The review flags the case as the Singleton anti-pattern and the design moves to injected configuration. Nothing about the surface resemblance was wrong; it simply wasn't structural.
How it works¶
The review starts from a library of the archetype's known failure look-alikes rather than from the pattern's positive requirements. For each, it records the surface markers that make it resemble the good pattern — and sets them aside as evidence of nothing — then tests the case for the disqualifying structural feature whose presence defines that anti-pattern. Detection of a named disqualifier converts the match into its failure twin.
Tuning parameters¶
- Library scope and freshness — how many look-alikes are catalogued and how current; a stale library silently misses newly recognized failure modes.
- Disqualifier strictness — how much of a disqualifying feature must be present to trigger the flag.
- Surface-marker discounting — how aggressively the tempting resemblances are set aside; over-discounting can wave away a genuine fit as if it were a look-alike.
When it helps, and when it misleads¶
It is strongest in fields that have accumulated named failure modes masquerading as good solutions — software engineering's "anti-pattern" is the canonical case.[1] It fails when the case's failure mode is novel and simply not in the catalog yet (it passes unflagged), or when zeal turns every proposed pattern into a suspected anti-pattern (chronic over-rejection). The guarding disciplines are to keep the library evidence-based and additive, and to require a named, specific disqualifier before flagging — not a general unease.
How it implements the components¶
surface_resemblance_log— it explicitly catalogs the tempting surface markers that make an anti-pattern look like the real pattern, and records them as non-probative.structural_fit_check— it tests the case for the specific disqualifying structural features whose presence converts the pattern into its anti-pattern (a fit check run in the negative).
It does NOT generate fresh counterexamples from history — that's Counterexample Search Session; it does not weigh the candidate against neighbour archetypes — that's Differential Pattern Review; and it does not set the necessary-feature gate for the *positive pattern — that's Pattern Fit Checklist.*
Related¶
- Instantiates: Archetype Overmatching Guardrail — the review guards specifically against the case where the pattern's own famous failure mode is mistaken for the pattern.
- Sibling mechanisms: Counterexample Search Session · Pattern Fit Checklist · Differential Pattern Review · Case Comparison Matrix · Pattern Fit Scoring Rubric · Precedent Distinction Memo · Red-Team Pattern Match Review · Review Queue · Decision Confidence Label
Editorial Notes¶
Form Classification¶
Form family: Assessment, Review & Assurance
Rationale: Checks the case against a catalog of the archetype's known look-alikes — situations that show the surface markers but carry a disqualifying feature — so a familiar-looking failure isn't mistaken for the pattern it mimics, making its operative form a bounded evaluation of existing evidence or work that produces a finding or disposition.
Independent corroboration: The frozen evidence defines Anti-Pattern Review as 'Checks the case against a catalog of the archetype's known look-alikes — situations that show the surface markers but carry a disqualifying feature — so a familiar-looking failure isn't mistaken for the pattern it mimics', so its operative form is Assessment, Review & Assurance.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Software anti-pattern practice supplies catalog-based recognition of superficially attractive structures with disqualifying failure conditions.
Related originating lineages:
- Architecture & Urban Planning — Pattern-language thinking supplies the positive-pattern counterpart.
- Engineering & Design (beyond software) — Failure-mode review compares designs to known unsafe configurations.
- Organizational & Management Science — Design and project reviews generalized anti-pattern checks to institutions.
- Systems Thinking & Cybernetics — System-archetype diagnosis contributes recurring structural patterns.
Review resolution: Software anti-pattern recognition is primary. Architectural pattern language, engineering review, organizational failure analysis, and systems structure materially shape the review; separating surface markers from disqualifying structure is synthesized here.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; high confidence.
References¶
[1] Brown, W. J., Malveau, R. C., McCormick, H. W., & Mowbray, T. J. AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis. John Wiley & Sons (1998). Catalogues named, recurring software-development, architecture, and project-management practices that appear useful but lead to harmful results. registry ↩ Show verification details
Supported in partVerified against the publisher's abstract
The book names and catalogues recurring software-development AntiPatterns, supporting the canonical case but not the claim that the method works best in fields with named failure modes.
“AntiPatterns identifies 40 of the most common AntiPatterns in the areas of software development, architecture, and project management.”