SDLC anti-patterns to reject
Reference catalogue. Cite the anti-pattern by name when blocking a
proposal — gives the user a clear vocabulary to discuss the issue.
Architecture anti-patterns
A-1. God service
Smell: One service does auth, billing, search, file storage, and email.
Why bad: Single deploy unit, single point of failure, every team
touches it, change velocity drops over time.
Fix: Split by business capability (DDD bounded context).
A-2. Distributed monolith
Smell: 12 microservices but they share a database and deploy together.
Why bad: All cost of distributed (latency, eventual consistency, ops
overhead) with none of the benefits (independent deploy, isolation).
Fix: Either truly separate (own DB, own deploy pipeline) or merge.
A-3. Synchronous chains
Smell: Request → Service A → Service B → Service C → Service D.
Why bad: Compound failure probability, p99 latency adds up.
Fix: Async with events, or co-locate hot path.
A-4. Premature optimization
Smell: Custom Redis Lua scripts, hand-tuned binary protocols, before
the first paying user.
Why bad: Complexity cost paid up front, never recouped.
Fix: Start simple. Optimize when you have load data.
A-5. Resume-driven development
Smell: "Let's use Kubernetes / GraphQL / event sourcing / DDD" with
no current pain it solves.
Why bad: Optimizes for engineer's resume, not user's outcome.
Fix: Ask "what's the simplest thing that could work?"
Plan / process anti-patterns
P-1. Big-bang rewrite
Smell: "Let's rewrite this in <new framework>."
Why bad: 80% of rewrites fail. The old system has years of bug fixes
baked in.
Fix: Strangler-fig. New behaviour in new code, old code coexists,
delete when traffic moves.
P-2. Hero culture
Smell: "Senior X always fixes the 3am incidents."
Why bad: Bus factor 1. X burns out. Knowledge doesn't transfer.
Fix: Runbooks, post-mortems, rotating on-call, pair-debugging.
P-3. No reversibility plan
Smell: Plan ships a one-way door (data migration, public API change,
breaking-contract release).
Why bad: If wrong, recovery is days or weeks.
Fix: Mandate dry-run + rollback path before approval.
P-4. Plan without timeboxes
Smell: Tasks named "implement feature X" with no end criteria.
Why bad: Open scope, time inflates to fit.
Fix: Each task ≤ 4 hours, with explicit "done = X" criteria.
Code-level anti-patterns
C-1. God class / God function
Smell: A class > 500 lines or function > 100 lines doing 5 unrelated things.
Why bad: Tests become integration tests. Diff readability collapses.
Fix: Single responsibility. Extract collaborators.
C-2. Stringly typed
Smell: Status passed as strings ("open", "closed", "blocked") with no enum.
Why bad: Typos compile. New status forgotten in switch.
Fix: Enum / discriminated union / branded type.
C-3. Catch-and-continue
Smell:
try { doThing(); } catch (e) { console.log(e); }
Why bad: Hides bugs. Silent corruption.
Fix: Catch only what you can handle; re-throw the rest; log with context.
C-4. Hardcoded secrets
Smell: API keys, passwords, DB URLs in source.
Why bad: Leaks in git history forever; rotation requires force-push (impossible).
Fix: Env vars or secret manager. Pre-commit hook to grep for sk-, ghp_, etc.
UI anti-patterns
Taken from Google AI Studio's guide to polishing generated interfaces (2026-09-16):
the fastest way to spot one is decoration that means nothing.
U-1. Chips that mean nothing
Smell: Status pills, badges, counters and tags that no state drives — "New", "Beta",
"AI", "3 insights" on a screen where nothing is new, beta, or counted.
Why bad: The reader cannot tell signal from ornament, so a real warning in the same
visual language is ignored. It is the most reliable tell of a generated UI.
Fix: Each chip names its meaning and the state behind it, or it is removed.
U-2. Placeholder imagery
Smell: Grey boxes, lorem photos, broken or hotlinked stock image URLs in a build
that is meant to be shown.
Why bad: The first impression is of an unfinished product; hotlinked assets break
or change without notice and may not be licensed.
Fix: Every image has a named source — generated for this product, owned, or
licensed — and is served from the product's own assets.
Incident / ops anti-patterns
O-1. No SLO
Smell: "Production seems slow today" but no SLO target.
Why bad: Can't tell breach from normal.
Fix: Set p99 latency, error rate, availability SLOs. Track burn.
O-2. Alert spam
Smell: Every error pages. Engineers stop reading alerts.
Why bad: Real incidents get missed in noise.
Fix: Page only on user-visible failure. Other signals to dashboard, not pager.
O-3. Post-mortem blame
Smell: "Engineer X deployed without testing."
Why bad: Suppresses future post-mortems. Blame doesn't fix the system.
Fix: Blameless post-mortems. Focus on missing guardrails, not the human.
O-4. Snowflake servers
Smell: "Don't reboot SRV-PROD-3, it has special config that's not in IaC."
Why bad: Disaster recovery impossible.
Fix: Everything in IaC. Servers are cattle, not pets.
How to use this catalogue
When you find one of these in a proposal/review:
- Cite the code (A-3, P-1, etc.) so the user has a vocabulary
- Quote the specific smell from the proposal
- Propose the specific fix
- If the user disagrees, capture as ADR with the alternatives section
filled in
When NOT to apply
- Hobby projects, learning exercises — anti-patterns are about scale
- Throwaway code with explicit
// TODO delete in 2 weeks
- Time-boxed POCs where the goal is "does the API actually work"