# 23. Anti-patterns

Common architect failure modes: cargo cult, ivory tower, distributed monolith, premature abstraction, resume-driven development, and lack of ownership.

- **Author:** Fedor Chishchin
- **Level:** advanced
- **Reading time:** ~25 minute read
- **Published:** 2026-05-23
- **Source:** https://fedorthinks.com/learn/software-architect-23-antipatterns

---

## 1. The core idea

An architectural mistake usually looks smart at the moment it's made — and expensive six months later.

### Cargo cult copies the shape without the reason

> Putting on a pilot's uniform doesn't mean you can land a plane.

Cargo cult architecture shows up when a team copies decisions made by big companies without their context: microservices, service mesh, Kafka, Kubernetes, event sourcing, multi-region. The problem isn't the tools — it's the absence of your own reason to use them.

The professional check is simple: which specific property are we buying, and why does it matter now?

### The ivory tower disconnects architecture from code

> A designer who's never been on a construction site risks producing a beautiful, unbuildable plan.

The ivory tower architect produces diagrams and standards but doesn't see real constraints: legacy, tooling, developer experience, incidents, deadlines, team skills. As a result, the decisions either don't get adopted or get adopted only on paper.

The architect doesn't have to write every line, but they have to stay close to delivery: reviews, prototypes, migrations, incidents, and feedback from the team.

## 2. Example and anti-example

You can only fix an anti-pattern after the team stops treating it as normal.

### Example: stop a premature abstraction

> A master key that opens everything usually opens a specific door badly.

The team wants to build a generic workflow engine for three similar approval flows. The architect proposes implementing two flows explicitly first, comparing the variability points, and only then extracting the abstraction.

That isn't a refusal to do architecture. It's protection against an abstraction that arrives before you understand the domain.

### Anti-example: resume-driven development

> Buying a tool for the shop window is risky — you're the one who has to work with it every day.

Engineers pick a technology because it looks good on a résumé or is fashionable at conferences. The team's skill set, the hiring market, maturity, tooling, operations, and long-term support don't enter the discussion.

The architect has to separate technological curiosity from value to the system.

#### Self-check

- Which decisions are we copying without our own reason?
- Where does the diagram disagree with the actual code?
- Where did an abstraction appear before the third concrete case?
- Which technologies were chosen for the team, and which for fashion?

Next module: [Continuous growth](./software-architect-24-growth).