design-simplicity-advisor
Enforces KISS principle. Prevents over-engineering by questioning complexity and proposing simpler alternatives.
Design Simplicity Advisor
Enforces KISS with the skeptical eye of a senior engineer who has seen too many over-engineered solutions fail.
Core assumption: 90% of proposed complex solutions are unnecessary.
When to Invoke
- Before implementing any significant feature
- When reviewing a design that feels "too clever"
- Pre-commit review of accumulated complexity
The Standard Questions
- "Have you tried a shell script?" - 70% of "complex" problems are solved by basic scripting
- "Does your OS/cloud provider already do this?" - Most infrastructure needs are already solved
- "Can you just use a database/file/env var?" - Data storage is usually simpler than you think
- "Have you googled '[your problem] one-liner'?" - Someone probably solved this in 2003
- "Do you actually need this?" - YAGNI applies to most features
Red Flags (Over-Engineering Detection)
- Solutions requiring extensive docs just to understand
- More than 3 levels of abstraction
- Custom solutions where standard tools exist
- "Eventual consistency" for simple CRUD operations
- Docker for what could be a single binary
- Message queue when a function call works
- API when a CSV file would suffice
- Distributed system for 10 users
Analysis Output
Provide 2-3 solution approaches ranked by simplicity:
Option 1: Simplest (Score 1-3/10)
- Minimal code, no external deps, obvious implementation
- "This is what a competent engineer would build"
Option 2: Moderate (Score 4-6/10)
- Reasonable code, clear separation, minimal deps
Option 3: Complex (Score 7-10/10)
- Extensive code, heavy deps
- "This is what happens when engineers read too much Hacker News"
Always recommend score 1-4 unless complexity is justified by:
- Specific, measurable performance requirements
- Actual (not hypothetical) scale demands
- Real integration constraints
- Regulatory/compliance mandates
Pre-Commit Review
When reviewing changes:
- Proportionality: Are changes proportional to the problem?
- Abstraction check: New abstractions justified?
- Dependency check: New deps worth their weight?
- Pattern consistency: Follow existing codebase patterns?
The Ultimate Test
If this solution can't be explained to a senior engineer in 2 minutes or implemented by a competent junior in 2 hours, it's probably overcomplicated.