AntiPattern Catalog
Developer, Architect, Manager
This book presents AntiPatterns from three major viewpoints: the software developer,
the software architect, and the software manager. Development AntiPatterns describe
situations the programmer meets when solving programming problems. Architectural
AntiPatterns focus on common problems in system structure, where many of the most serious
unresolved failures live. Management AntiPatterns describe problems and solutions rooted
in the software organization, and they affect people in every role.
All three viewpoints share a reference model: Root Causes (the fundamental
context for an AntiPattern), Primal Forces (the key motivators of the decisions that
went wrong), and the Software Design Level Model (which defines the scale a given
pattern applies at).
SHEET 03 · OFFICIAL SHORT CATALOG (BOOK 1 NAMES)
Full literary form: AntiPatterns (Wiley 1998), chapters 5–7. This page is the official short catalog, not the book.
Development
The Blob — One class or object monopolizes behavior. Alias: God Class. Refactor toward distribution of responsibility.
Lava Flow — Dead or half-dead code left in place because no one will touch it. Refactor toward deletion with tests.
Spaghetti Code — Control flow with no discernible structure. Refactor toward modules with names that mean something.
Cut-and-Paste Programming — Reuse by duplication. Refactor toward a single abstraction.
Golden Hammer — A familiar tool applied to every problem. Refactor toward choosing the tool after the problem.
Poltergeists — Short-lived objects that exist only to pass messages. Refactor toward collapsing the ghost.
Functional Decomposition — Procedural design wearing object clothing. Refactor toward objects that own data and behavior.
Boat Anchor — A costly component kept because it was costly. Refactor toward removal.
Dead End — A customization or product path with no way forward. Refactor toward a supported path or an exit.
Architecture
Stovepipe System / Stovepipe Enterprise — Point-to-point integration, no shared abstraction. Refactor toward a defined architecture.
Vendor Lock-In — Architecture that cannot change vendor without a rewrite. Refactor toward isolation at the boundary.
Design by Committee — Design that satisfies every stakeholder and no user. Refactor toward a named architect and a cut list.
Architecture by Implication — No written architecture, it lives only in the code. Refactor toward a short spec that can be wrong in public.
Cover Your Assets — Documents that list options and decide nothing. Refactor toward a decision record.
Wolf Ticket — A claimed standard or product capability that is not there. Refactor toward a running spike.
Swiss Army Knife — An interface that tries to do every job. Refactor toward small, purpose-built surfaces.
Reinvent the Wheel — Building what already exists, badly. Refactor toward adoption with eyes open.
Management
Analysis Paralysis — Modeling past the point of useful knowledge. Refactor toward a thin slice in production.
Death by Planning — The plan is the product. Refactor toward replanning from facts.
Viewgraph Engineering — Slides instead of software. Refactor toward a build.
Mushroom Management — Keep the team in the dark. Refactor toward visible status and actual users.
Blowhard Jamboree — Industry pundits driving technical choice. Refactor toward a decision owner who has to live with it.
Project Mismanagement — No one is actually managing the work. Refactor toward a single accountable manager.
Corncob — A difficult person allowed to steer the project by friction. Refactor toward a managed conflict or an exit.
Smoke and Mirrors — A demo of what does not exist. Refactor toward a true status.
Intellectual Violence — Obscure theory used as status, not as a tool. Refactor toward explanations a peer can check.
Books 2 and 3 get their own short lists in a later update.