Explore the Catalog
🧭
What Are Antipatterns?
A pattern that goes from a problem to a bad solution.
🔬Signature Widget — Smell Detector Workbench
Specimen #1 — A method that does everything
Diagnose the dominant antipattern. Reveal the cure on submit.
Medium severity
Score 0/0
🔎 Code Specimen1 / 7
String processOrder(String item, int qty, boolean isMember, String country) { if (item == null || item.isEmpty()) return "ERROR"; if (qty <= 0) return "ERROR"; double price; if (item.equals("book")) price = 12.0; else if (item.equals("pen")) price = 1.5; else return "ERROR"; double sub = price * qty; double disc = 0; if (isMember && sub > 100) disc = sub * 0.10; else if (isMember) disc = sub * 0.05; double ship = country.equals("US") ? 5 : 25; if (sub - disc > 200) ship = 0; return "OK " + (sub - disc + ship);}🎯 Pick the dominant antipattern
🧭
What Are Antipatterns?
A pattern that goes from a problem to a bad solution.
Brown, Malveau, McCormick, and Mowbray coined the term in AntiPatterns (Wiley, 1998) as the deliberate counterpart of the GoF design-pattern catalog. Where a design pattern starts with a well-defined problem and maps to a tried-and-true solution, an antipattern starts with a poorly defined situation and maps to a tempting-looking solution that always turns out to be a mistake. The antipattern record looks almost identical to a GoF record — Name, Context, Problem, Symptoms, Consequences — except that the closing slot says Refactoring (the way out) instead of Known Uses. A code smell (Kent Beck, popularised by Fowler) is the lower-rung cousin: a hint that an antipattern may be lurking, surfaced by something visible in the code (a 300-line method, a parameter list of nine booleans, a class named Manager).
Key Ideas
- A design pattern catalogs a good recurring solution; an antipattern catalogs a recurring mistake plus the way back to safety.
- The six-part anatomy mirrors the GoF record: Name, Type (Dev / Architecture / Project-Management), Problem, Symptoms, Consequences, Refactoring.
- A code smell is observable in the code itself (LOC, parameter count, duplication). It is the signal; the antipattern is the diagnosis.
- Antipatterns span three categories — Development (Spaghetti, God Class), Architecture (Stovepipe, Big Ball of Mud), Project Management (Death March, Analysis Paralysis).
- The cure is almost always a positive pattern or principle you already know — SRP, ISP, DRY, DI, Strategy, Extract Method.
🪤Why It Tempts You
- ★Naming bad patterns creates a shared vocabulary — "this is a God Class" is faster than a five-minute critique.
- ★Documented refactoring paths transfer expertise from senior to junior developers without an in-person mentor.
- ★Categorising by Development / Architecture / Project-Management makes the right team responsible for the fix.
- ★Reading the antipattern catalog before writing code lets you avoid mistakes you have never personally made.
⚠️What Goes Wrong
- △Labels can become buzzwords — calling everything "spaghetti" loses the diagnostic edge.
- △Misdiagnosing a legitimate design as an antipattern can be more harmful than the smell itself.
- △Categories overlap — a God Class is also a Spaghetti Method and an SRP violation, depending on which axis you measure on.
In the wild:When a team adopts a shared antipattern vocabulary, code reviews shorten dramatically: a reviewer can write "God Class — extract IImportExport" instead of three paragraphs of prose. The same vocabulary scales to architecture reviews ("this is a Stovepipe — let's widen the seam") and even to retrospectives ("we shipped on a Death March schedule — let's renegotiate scope next quarter").
Code Snippets
Quiz
What Are Antipatterns? Quiz
QUIZ 1/7What is the *structural* difference between a GoF design-pattern record and a Brown et al. antipattern record?
Diagrams
Both records share the same shape: Problem / Context → Solution → Consequences. The decisive difference is the closing arc: a Design Pattern leads from Solution to Benefits, Consequences, Related Solutions; an Antipattern's Solution is itself the trap, so the arrow continues into Symptoms & Consequences, then to a Refactored Solution that takes you back to safety. The dashed arrow between the two is the historical observation that yesterday's pattern can drift into today's antipattern as context changes — the Singleton is the canonical example.
The taxonomy is who fixes it, not what kind of code smells. Development antipatterns are fixed by programmers in code reviews and refactor sprints. Architecture antipatterns are fixed by architects through layering, service boundaries, and migration plans. Project-management antipatterns are fixed by managers renegotiating scope, schedule, or staffing. Sorting an antipattern into the right category is the first step toward an actionable conversation — telling a developer to fix a Death March is as misplaced as telling a manager to fix Spaghetti Code.
Practice
Sort each antipattern under the category Brown et al. assign to it. Some categories overlap — pick the one the original catalog uses.
EXERCISE 1/4Spaghetti Code
God Class / Blob
Copy-Paste Programming
Lava Flow
Stovepipe System
Vendor Lock-in
Big Ball of Mud
Death March
Analysis Paralysis
🛠️ Development
🏛️ Architecture
📋 Project Management
Find the responsibility the GodClassStudent should NOT carry
EXERCISE 2/4Click on the line you think contains the bug, then press Confirm.
Antipattern misconceptions — true or false?
EXERCISE 3/4Singleton is always an antipattern and should never be used.
Copy-paste programming is acceptable for the first two occurrences (Rule of Three).
A God Class is the same as a Spaghetti Code antipattern.
Premature optimization is the root of all evil.
Magic Numbers are always a problem; every literal in code must be named.
Reinventing the Wheel is the same antipattern as Golden Hammer.
Order the five steps that refactor a God Class into SRP-respecting collaborators
EXERCISE 4/4Drag the lines into the correct order.
3. Introduce an interface in front of each new class (IImportExport, IStudentDbOperations, ...).
1. Identify cohesive groups of methods (DB calls / IO / validation / formatting).
5. Replace direct God-Class calls with dependency injection of the new interfaces.
2. Extract each group into its own new class — keep the data class as a passive POJO.
4. Update the original data class to expose only its fields (and minimal data-derived accessors).