Keep It Simple, Stupid. Four words that sum up one of the hardest virtues to practise in software development: don't over-engineer, don't anticipate, don't complicate what can stay simple.
The KISS principle — Keep It Simple, Stupid — originates from the US Navy in the 1960s. In software engineering, it expresses a fundamental idea: a system works better when it stays simple rather than complicated. Simple doesn't mean simplistic or naive — it means complexity is only introduced when it is genuinely necessary.
Simple ≠ simplistic
Simplicity is work. It is often easier to write complex code than simple code. Simple code is readable, testable, and modifiable. Complex code often reflects insufficiently clarified thinking, or anticipation of needs that may never materialise.
The traps of over-engineering
- Premature abstractions: creating interfaces and abstract classes before having two concrete implementations
- Unnecessary design patterns: applying a pattern because it's elegant, not because it solves a real problem
- Excessive genericity: designing a system capable of handling all possible cases, including those that will never occur
- Unnecessary indirection: multiplying layers, wrappers, and adapters for "future flexibility"
KISS + YAGNI + DRY
KISS works alongside two other principles:
- YAGNI (You Aren't Gonna Need It — don't implement what you don't yet need)
- DRY (Don't Repeat Yourself — avoid duplication). Together, they guard against accidental complexity, which Fred Brooks distinguishes from essential complexity — that inherent to the problem being solved.
When simplicity is counterproductive
KISS has its limits. Some domains are intrinsically complex: finance, healthcare, high-availability distributed systems. Over-simplifying a rich domain means ignoring its reality. In these cases, Domain-Driven Design and careful modelling are more appropriate than parsimony.
The goal is not to write as little code as possible — it's to write only the necessary code.