Skip to content

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.*

  • 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:

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] An anti-pattern is a commonly-reached-for "solution" that looks appropriate but reliably makes things worse; the term was popularized in software engineering by Brown et al., AntiPatterns (1998). The mechanism generalizes the idea — a catalog of a pattern's look-alike failures — to any archetype. registry