KISS Principle
Also Known As
KISS
Keep It Simple Stupid
simplicity principle
TL;DR
Keep It Simple, Stupid — prefer the simplest solution that solves the problem over clever or complex abstractions.
Explanation
KISS (variously: Keep It Simple, Stupid; Keep It Short and Simple) advocates simplicity as a primary design goal. Unnecessary complexity is the root cause of many bugs and maintenance burdens — complex code is harder to understand, harder to test, and harder to change. KISS is not an argument against abstraction but against incidental complexity: solve the essential complexity of the problem without adding accidental complexity through clever patterns, premature optimisation, or speculative architecture.
Common Misconception
✗ KISS means avoiding all abstractions and patterns. It means solving the actual problem without unnecessary complexity — a well-placed design pattern that genuinely simplifies future change is KISS-compliant; premature abstraction is not.
Why It Matters
Unnecessarily complex solutions are harder to understand, maintain, and debug — simplicity is a feature, and KISS forces the question: 'can this be solved more directly?'
Common Mistakes
- Implementing a design pattern because it is a 'best practice' when a simple function or array would solve the problem.
- Adding abstraction layers before there is evidence they are needed — YAGNI is KISS's sibling.
- Over-engineering error handling: try/catch around every single line rather than at appropriate boundaries.
- Mistaking familiarity with simplicity — a pattern you know well may still be overkill for the problem.
Avoid When
- Using simplicity as an excuse to skip error handling, logging, or security controls — simple code still needs to be correct.
- Conflating simple with familiar — a recursive solution may be simpler than an imperative one even if it looks less familiar.
- Oversimplifying until the code no longer handles real edge cases — simplicity must not sacrifice correctness.
When To Use
- When reviewing a solution that has grown complex — ask whether a simpler approach solves the same problem.
- Architecture decisions — prefer the simplest design that meets the requirements, not the most flexible one imaginable.
- Code review — flag unnecessary abstraction, premature generalisation, and clever tricks that obscure intent.
- Teaching and onboarding — simple, readable code is self-documenting and lowers the learning curve.
Code Examples
💡 Note
Add abstraction layers only when there is a concrete, present reason — not a speculative one.
✗ Vulnerable
// Over-engineered: AbstractStrategyFactoryBuilderProvider
class UserSorterStrategyFactoryBuilderProvider {
public function buildStrategyFactory(): UserSorterStrategyFactory { ... }
}
✓ Fixed
// KISS: just a function
function sortUsersByName(array $users): array {
usort($users, fn($a, $b) => strcmp($a->name, $b->name));
return $users;
}
Tags
🤝 Adopt this term
£79/year · your link shown here
Added
15 Mar 2026
Edited
25 Mar 2026
Views
22
🤖 AI Guestbook educational data only
|
|
Last 30 days
Agents 1
No pings yesterday
Amazonbot 7
Perplexity 3
Google 3
Ahrefs 2
Majestic 1
Unknown AI 1
Also referenced
How they use it
crawler 16
crawler_json 1
Related categories
⚡
DEV INTEL
Tools & Severity
🔵 Info
⚙ Fix effort: Low
⚡ Quick Fix
Before adding abstraction, ask: does this complexity exist in the problem domain or did I create it? — if the latter, remove it
📦 Applies To
PHP 5.0+
web
cli
queue-worker
🔗 Prerequisites
🔍 Detection Hints
Multiple abstraction layers wrapping simple operations; factory factory factories; over-engineered simple CRUD
Auto-detectable:
✗ No
phpstan
⚠ Related Problems
🤖 AI Agent
Confidence: Low
False Positives: High
✗ Manual fix
Fix: High
Context: File
Tests: Update