Software Architect · Module 23
Anti-patterns aren't useful for blame. They give you the vocabulary to catch systemic thinking errors earlier.
Cargo cult · ivory tower · distributed monolith · premature abstraction
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.
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.
- 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?