Should I Buy It?
Keep it simple. Simplicity is a design goal, not a constraint. A system must be able to function — and be repaired — even under degraded conditions.
Origin
Kelly Johnson (1910–1990) was the chief engineer of Lockheed’s Skunk Works division, responsible for some of the most advanced aircraft in history: the U-2, the SR-71 Blackbird, the F-117.
The paradox of his position: designing cutting-edge aircraft that also had to be repairable in the field by an ordinary mechanic, with a handful of basic tools. It was from this concrete constraint that the KISS principle was born.
Johnson would literally hand his engineers a set of tools and say: the plane you design must be repairable with these, under combat conditions. The “stupid” wasn’t aimed at the engineers — it referred to the gap between the system’s sophistication and the means available to fix it.
The U.S. Navy formalized the principle in 1960, but Johnson was applying it well before that.
The Theory
The KISS principle rests on a simple observation: unnecessary complexity is a liability. The more components a system has, the more potential failure points it carries. The harder it is to understand, the harder it is to maintain, repair, or adapt.
Simplicity is not a design flaw — it is an active goal to pursue. A simple system that fulfills its function is worth more than a sophisticated system that fulfills it equally well but fails at the wrong moment.
The variants of the principle are numerous:
- “Keep it short and simple”
- “Keep it simple and straightforward”
- In Unix philosophy: “Do one thing and do it well”
All converge on the same intuition: the value of a system is measured by what it accomplishes, not by the complexity of its internal mechanism.
In Practice
In software engineering: Less code means fewer bugs. The Unix philosophy (one tool = one function) has produced systems of remarkable longevity precisely because each component is understandable in isolation.
In interface design: Visual complexity harms usability. Interfaces that demand the least mental effort upfront are the ones users adopt and stick with.
In communication: A short, clear message travels better than an exhaustive one. Exhaustiveness is often a form of intellectual protection — “I’ve covered everything” — that harms actual transmission.
In automation: A 5-step workflow that rarely breaks is worth more than a 30-step workflow that does the same thing but requires constant maintenance. Every additional block is a potential failure point.
Nuances and Limits
KISS does not say everything must be trivial. Some problems are inherently complex and require complex solutions. The question is: is this complexity necessary, or is it the result of poor design?
There is a difference between apparent simplicity (hiding complexity behind a simple interface) and genuine simplicity (a system that is no more complex than it needs to be). Both have their place, but the latter is more robust.
KISS and Gall’s Law complement each other: KISS says “aim for simplicity,” Gall says “even if you wanted to design something complex from the start, it wouldn’t work.” Together they form a coherent argument for starting simple, validating, and adding complexity with care.
Sources: Wikipedia — KISS principle · Wikipedia — Kelly Johnson