simplification-cascades
Simplification Cascades
Overview
Sometimes one insight eliminates 10 things. Look for the unifying principle that makes multiple components unnecessary.
Core principle: "Everything is a special case of..." collapses complexity dramatically.
Quick Reference
| Symptom | Likely Cascade |
|---|---|
| Same thing implemented 5+ ways | Abstract the common pattern |
| Growing special case list | Find the general case |
| Complex rules with exceptions | Find the rule that has no exceptions |
| Excessive config options | Find defaults that work for 95% |
The Pattern
Look for:
- Multiple implementations of similar concepts
- Special case handling everywhere
- "We need to handle A, B, C, D differently..."
- Complex rules with many exceptions
Ask: "What if they're all the same thing underneath?"
Examples
Cascade 1: Stream Abstraction
Before: Separate handlers for batch/real-time/file/network data Insight: "All inputs are streams - just different sources" After: One stream processor, multiple stream sources Eliminated: 4 separate implementations
Cascade 2: Resource Governance
Before: Session tracking, rate limiting, file validation, connection pooling (all separate) Insight: "All are per-entity resource limits" After: One ResourceGovernor with 4 resource types Eliminated: 4 custom enforcement systems
Cascade 3: Immutability
Before: Defensive copying, locking, cache invalidation, temporal coupling Insight: "Treat everything as immutable data + transformations" After: Functional programming patterns Eliminated: Entire classes of synchronization problems
Process
- List the variations - What's implemented multiple ways?
- Find the essence - What's the same underneath?
- Extract abstraction - What's the domain-independent pattern?
- Test it - Do all cases fit cleanly?
- Measure cascade - How many things become unnecessary?
Red Flags You're Missing a Cascade
- "We just need to add one more case..." (repeating forever)
- "These are all similar but different" (maybe they're the same?)
- Refactoring feels like whack-a-mole (fix one, break another)
- Growing configuration file
- "Don't touch that, it's complicated" (complexity hiding pattern)
Remember
- Simplification cascades = 10x wins, not 10% improvements
- One powerful abstraction > ten clever hacks
- The pattern is usually already there, just needs recognition
- Measure in "how many things can we delete?"
More from fimoklei/pm-ai-playbook
first-principles-decomposer
Break any problem down to fundamental truths, then rebuild solutions from atoms up. Use when user says "firstp", "first principles", "from scratch", "what are we assuming", "break this down", "atomic", "fundamental truth", "physics thinking", "Elon method", "bedrock", "ground up", "core problem", "strip away", or challenges assumptions about how things are done.
20optimize-docs
Condense markdown documentation for token efficiency while preserving all semantic meaning. Use when rules, documentation, or config files need optimization. Target 25-40% reduction through systematic condensation patterns.
18idea-challenger
Pre-launch red team analysis that identifies failure modes and validates assumptions before resource commitment. Use when evaluating new products/features/strategies, before significant resource allocation, when stakeholders seem overly optimistic, or when cost of failure would be high (reputation, budget, market position).
18pre-mortem-analyst
Imagine the project already failed, then work backward to find why. More powerful than risk assessment because it assumes failure is certain. Use when user says "pre-mortem", "premortem", "imagine this failed", "what could go wrong", "risk analysis", "before we launch", "stress test", "what would kill this", "project risks".
18inversion-strategist
Flip problems upside down - instead of "how to succeed", ask "how to definitely fail" then avoid those paths. Use when user says "invert", "inversion", "flip it", "opposite approach", "how would this fail", "avoid failure", "what NOT to do", "Munger", "anti-goals", "guarantee failure".
18security-threat-model
Repository-grounded threat modeling that enumerates trust boundaries, assets, attacker capabilities, abuse paths, and mitigations, and writes a concise Markdown threat model. Trigger only when the user explicitly asks to threat model a codebase or path, enumerate threats/abuse paths, or perform AppSec threat modeling.
16