Why

Five Whys Analysis

Apply Five Whys root cause analysis to investigate issues by iteratively asking "why" to drill from symptoms to root causes.

Description

Iteratively ask "why" to move from surface symptoms to fundamental causes. Identifies systemic issues rather than quick fixes.

Usage

/why [issue_description]

Variables

• ISSUE: Problem or symptom to analyze (default: prompt for input)
• DEPTH: Number of "why" iterations (default: 5, adjust as needed)

Steps

1. State the problem clearly
2. Ask "Why did this happen?" and document the answer
3. For that answer, ask "Why?" again
4. Continue until reaching root cause (usually 5 iterations)
5. Validate by working backwards: root cause → symptom
6. Explore branches if multiple causes emerge
7. Propose solutions addressing root causes, not symptoms

Examples

Example 1: Production Bug

Problem: Users see 500 error on checkoutWhy 1: Payment service throws exceptionWhy 2: Request timeout after 30 secondsWhy 3: Database query takes 45 secondsWhy 4: Missing index on transactions tableWhy 5: Index creation wasn't in migration scriptsRoot Cause: Migration review process doesn't check query performance
Solution: Add query performance checks to migration PR template

Example 2: CI/CD Pipeline Failures

Problem: E2E tests fail intermittentlyWhy 1: Race condition in async test setupWhy 2: Test doesn't wait for database seed completionWhy 3: Seed function doesn't return promiseWhy 4: TypeScript didn't catch missing return typeWhy 5: strict mode not enabled in test configRoot Cause: Inconsistent TypeScript config between src and tests
Solution: Unify TypeScript config, enable strict mode everywhere

Example 3: Multi-Branch Analysis

Problem: Feature deployment takes 2 hours
Branch A (Build):Why 1: Docker build takes 90 minutesWhy 2: No layer cachingWhy 3: Dependencies reinstalled every timeWhy 4: Cache invalidated by timestamp in DockerfileRoot Cause A: Dockerfile uses current timestamp for versioning
Branch B (Tests):Why 1: Test suite takes 30 minutesWhy 2: Integration tests run sequentiallyWhy 3: Test runner config has maxWorkers: 1Why 4: Previous developer disabled parallelism due to flaky testsRoot Cause B: Flaky tests masked by disabling parallelism
Solutions: A) Remove timestamp from Dockerfile, use git SHAB) Fix flaky tests, re-enable parallel test execution

Notes

• Don't stop at symptoms; keep digging for systemic issues
• Multiple root causes may exist - explore different branches
• Document each "why" for future reference
• Consider both technical and process-related causes
• The magic isn't in exactly 5 whys - stop when you reach the true root cause
• Stop when you hit systemic/process issues, not just technical details
• Multiple root causes are common—explore branches separately
• If "human error" appears, keep digging: why was error possible?
• Document every "why" for future reference
• Root cause usually involves: missing validation, missing docs, unclear process, or missing automation
• Test solutions: implement → verify symptom resolved → monitor for recurrence