Manu's Vault

Architecture Decision Anti Patterns

3 min readStatus:Seedling

Core Idea

Architecture Decision Anti-Patterns are dysfunctional behaviors that undermine the architecture decision-making process, leading to poor decisions, repeated debates, lost context, and inability to evaluate outcomes. The three primary anti-patterns are Covering Your Assets, Groundhog Day, and Email-Driven Architecture.

What Are Architecture Decision Anti-Patterns?

Unlike technical anti-patterns (Big Ball of Mud, God Objects), these are process anti-patterns — failures in the social and organizational mechanisms around decision-making. They emerge when architects and teams lack clear decision-making processes, documentation standards, and accountability mechanisms.

Three Critical Anti-Patterns (Richards and Ford):

1. Covering-Your-Assets-Anti-Pattern:

  • Making decisions without clear justification, leaving room to deflect blame if they fail
  • Decisions are deliberately vague or non-committal so the architect can later claim “I never actually recommended that”

2. Groundhog-Day-Anti-Pattern:

  • Repeatedly debating the same decisions because they were never formally documented
  • New team members raise the same questions and trigger the same debates — consuming time without producing new insights
  • Example: re-arguing microservices vs. monolith because no record exists of the previous decision and its rationale

3. Email-Driven-Architecture-Anti-Pattern:

  • Making critical decisions through informal email threads, Slack messages, or hallway conversations
  • Decision context, alternatives, and rationale scatter across communication channels and become impossible to reconstruct

Common Root Cause: The absence of structured decision-making and documentation. Without formal Architecture-Decision-Records or equivalent mechanisms, teams fall into these dysfunctional patterns by default.

Why This Matters

Architecture Decision Anti-Patterns create severe long-term consequences:

  • Lost institutional knowledge: As team members leave, undocumented context disappears
  • Repeated debates: Without records, teams re-argue the same questions, wasting time and creating frustration
  • Inability to evaluate decisions: If you don’t know why a decision was made, you can’t assess whether it achieved its goals
  • Eroded trust: Decisions lacking transparency cause developers to lose faith in architects
  • Poor onboarding: New team members can’t understand existing choices, leading to proposals that contradict established patterns

Avoiding these anti-patterns requires deliberate investment in documentation practices like ADRs, which capture the status, context, decision, and consequences of each significant architectural choice.

Sources

Note

This content was drafted with assistance from AI tools for research, organization, and initial content generation. All final content has been reviewed, fact-checked, and edited by the author to ensure accuracy and alignment with the author’s intentions and perspective.

Graph View

Backlinks