Software architecture · Level 6: Governance and evolution · Module 31 of 46

Architecture antipatterns

An antipattern is a solution that looks reasonable, gets used again and again, and reliably makes things worse. Architecture antipatterns are especially costly because they're hard to reverse and often invisible until a system is in trouble. Naming them helps: once a team can say "this is architecture by implication", it can stop doing it. This module collects the antipatterns met across the track and adds the classic ones about how architects themselves think.

1. The idea

Bad habits in driving. Each one feels sensible in the moment: following too closely to stop people cutting in, braking hard because a car once came out of a side road. Driving instructors give them names so new drivers recognise them early. Naming an architecture antipattern does the same: it turns a vague unease into something a team can spot and discuss.

The catalogue

Antipattern	What happens	Where
Frozen caveman	An architect keeps raising one fear from a past disaster, whatever the current context	Below
Architecture by implication	No deliberate architecture: the framework's defaults and early code decide it	Below
Accidental complexity	Complexity added by our choices rather than demanded by the problem	Below
Stovepipe systems	Systems built in isolation that duplicate data and features and can't work together	Below
Cart before the horse	Choosing a technology or style before understanding the characteristics	Module 17
Generic architecture	Trying to support every characteristic; good at nothing	Module 04
Out-of-context scorecard	Counting criteria that don't matter here	Module 06
Entity trap	Components that mirror tables; logic scattered in callers	Module 08
Architecture sinkhole	Requests passing through layers that do nothing	Module 11
Swarm of gnats	Many tiny events instead of meaningful business events	Module 14
Microservice all the things	Splitting every noun into a service	Module 16
Groundhog Day, email-driven architecture, covering your assets	Decisions re-debated, scattered in mail, or avoided	Module 27
Elephant migration	Migrating everything at once	Module 30

Four more, in brief

Frozen caveman: an architect once suffered a database outage, so every design review now ends on "but what if the database goes down?", even for a static website. Experience is valuable; applied out of context it's a veto, not analysis.
Architecture by implication: nobody decides the structure, so it emerges from the web framework's generators and whatever the first developers did. Ask "what are the top three characteristics?" and nobody knows.
Accidental complexity: complexity that comes from our tools and choices (an event bus for three calls, five layers for a form) rather than from the problem. Essential complexity can't be removed; accidental complexity can.
Stovepipe systems: departments build their own systems, each with its own customer list and its own copy of the same logic. Each works; together they can't share data and disagree about the facts.

2. How it works

The frozen caveman in a design review

Architecture by implication

A new product, built quickly with no architecture decisions. Watch where the structure comes from, and what happens when the business asks for something new.

3. Try it yourself

Diagnose the antipattern

Ten short scenarios. Pick the antipattern each one describes, then read why.

4. Trade-offs

Experience vs fresh analysis

Past disasters are real lessons. The question is whether this context has the same forces. Ask, then decide; don't veto by memory.

Speed vs deliberate design

Skipping architecture decisions is fast at first. A few hours naming the top characteristics and the structure saves months later. Decide the expensive things deliberately, even if quickly.

Sophistication vs simplicity

Every pattern in this track adds complexity. Use one when a characteristic needs it, not because it's available.

Local optimum vs shared

A team's own system is fastest for that team; stovepipes are the result. Some things (customer identity, core reference data) are worth sharing even at the cost of coordination.

5. In real projects

Use the names gently. "That looks like the entity trap" opens a discussion; "you've built an antipattern" closes one. Names are tools for spotting patterns, not for blame.

Review for antipatterns regularly. In architecture reviews, scan the catalogue: are any present, or emerging? Several (sinkhole, entity trap, cycles) can be detected by fitness functions (Module 26).

Check yourself. The frozen caveman and covering your assets are about the architect's own thinking. Ask whether your strongest objections come from this system's context or from a scar.

Say it in the interview

Two-sentence answers

"Name an architecture antipattern you've seen." Pick one you've genuinely met, say what it cost, and how it was fixed or would be. Architecture by implication and the entity trap are common and easy to explain.
"What's accidental complexity?" Complexity introduced by our solution rather than required by the problem. It's the part we can remove, and every pattern we add risks increasing it.
"What's the frozen caveman?" An architect who applies one past bad experience to every situation regardless of context. The cure is to ask what risk this context actually has.

Red flags interviewers notice

Not being able to name a single mistake in a system you designed.
Using antipattern names to dismiss colleagues' work.
Adding patterns to an answer to sound sophisticated.

6. Remember it

Memory hook: "Name it to notice it"Antipatterns hide because each step feels reasonable. A name lets the team see the pattern.

How this hook works: what "name it to notice it" means

What the slogan means, phrase by phrase

"Name it": Give the recurring mistake a shared label.
"to notice it": Once named, people recognise it early, before it's expensive.

Why this picture fits: every antipattern is a series of individually sensible decisions; only a name makes the series visible.

The story → the concept

Driving habits	Architecture
Braking hard at every junction after one scare	Frozen caveman
Driving with no route planned	Architecture by implication
A six-speed sports car for the school run	Accidental complexity
Each family member with their own car and map	Stovepipe systems

The trap it saves you from

Repeating a well-known mistake because nobody had a word for it.

7. Common mistakes

No decisions at allArchitecture by implication is the most common antipattern of all: the structure exists anyway, just undesigned.

Pattern collectingUsing every pattern from a book in one system. Each solves a problem; without the problem, it's accidental complexity.

Scars as rulesTurning one past incident into a permanent veto, whatever the context.

Blame by labelAntipattern names used to win arguments rather than improve systems.

8. Design exercise (30 minutes)

Scan your system (15 min). Go through the catalogue table. For each antipattern, write "absent", "emerging" or "present" for a system you know, with evidence.
Pick one to fix (10 min). For the most costly one, write the first small step to reduce it.
Check yourself (5 min). Which objection do you raise in almost every design review? Is it always relevant?

9. Self-check quiz

No one has decided the architecture; it's whatever the framework generated. Which antipattern?

The structure was implied, never chosen.

Complexity from our own choices of tools and patterns, not from the problem, is called:

Accidental complexity can be removed; essential can't.

An architect blocks a caching proposal for an internal reporting tool because a cache once caused a pricing bug at a previous job. Which antipattern?

A past scar applied without checking whether this context shares the risk.

Sales, support and billing each built their own customer database, and they disagree about addresses. Which antipattern?

Isolated systems duplicating data and features.

What is naming an antipattern for?

Name it to notice it.

10. Go deeper

Resource	Time	Why
Fundamentals of Software Architecture, 2nd edition	book	Architect and decision antipatterns, including the frozen caveman.
No Silver Bullet (Fred Brooks)	30 min	The essay that separated essential from accidental complexity.
Microservices AntiPatterns and Pitfalls (Mark Richards)	short book	Antipatterns specific to distributed architectures.