KISS — Keep It Simple, Stupid

“Designs and systems should be as simple as possible.” — Kelly Johnson (Lockheed Skunk Works, c. 1960)

The Claim

Among systems that work, prefer the simpler one. Simpler systems have fewer failure modes, fewer dependencies, smaller surface area for bugs, easier onboarding, faster debugging, and lower operational load.

Kelly Johnson’s original framing was a mechanical-engineering constraint: aircraft components must be repairable by the average mechanic, with average tools, in field conditions. The software analogue: systems must be understandable by the average engineer (including the future you at 3am), with average tools, under production pressure.

Why It Holds

Complexity has non-linear costs:

• Debugging is harder than writing (see kernighans-law). The debugger has to understand the code — which is harder than writing it was — and complex code multiplies that cost.
• Onboarding is O(complexity). New team members take longer to become productive; brooks-law bites harder.
• Failure modes multiply combinatorially with components. Three services, each 99.9% reliable, combine to 99.7% reliable. Ten services drop to 99.0%.
• Edge cases are quadratic in the number of features that can interact.

The simpler system still works when you’re tired, when it’s 2am, when the senior engineer is on vacation, when the docs are out of date.

In This Wiki

• occams-razor applied to design. Among designs that meet requirements, prefer the simplest. Occam in epistemology; KISS in engineering.
• Respects galls-law. “A complex system that works is invariably found to have evolved from a simple system that worked.” KISS tells you where to start; Gall tells you what happens to simple systems over time. Together: start simple; accept complexity as it’s justified.
• Companion to YAGNI. YAGNI is KISS applied prospectively: don’t build the feature you don’t need yet. KISS is retrospective and continuous: every feature you add should be as simple as it can be.
• Tensioned with DRY. Over-DRY code is often more complex than the duplication would have been. When DRY and KISS conflict, the usual answer is KISS first, DRY when the duplication has been observed three times.
• Defends against second-system-effect. The “bloated, overengineered replacement” is the violation of KISS produced by a designer who just shipped a successful first system and now feels confident enough to build something “properly.” KISS is the corrective.
• Defends against the dunning-kruger-effect. Confident novices build complex systems because they cannot yet see which complexity is necessary and which is self-inflicted. Experts build simpler systems because they know which complexity actually earns its keep.
• Connects to first-principles-thinking. First-principles reasoning tells you what’s actually necessary. KISS says: build exactly that, and no more.

The Einstein Corollary

“Everything should be made as simple as possible, but no simpler.” Oversimplified systems fail differently than overcomplex ones — they omit essential behaviour, mishandle corner cases, and collapse under load. KISS is bounded below by adequacy.

The trade-off: under-simple systems miss requirements; over-simple systems fail gracelessly at scale; over-complex systems collapse under their own weight. The sweet spot is minimal-adequate, not minimal.

Software Examples

• Choose boring technology. The Postgres + monolith + cron stack is simpler than microservices + Kafka + Kubernetes + service mesh, and solves most problems better. Reach for the complex stack only when the simple one provably won’t work.
• Fewer services. Every service boundary is a distributed systems problem. Merge services that always deploy together.
• Fewer dependencies. Every library is a potential supply-chain risk, version conflict, and security CVE. Prefer the standard library unless the dependency earns its keep.
• Less cleverness. The ternary nested in the list comprehension that saves three lines and costs an hour of debugging is a KISS violation.

Limits

1. Simplicity is context-dependent. What’s simple for a Rust expert is complex for a Python team, and vice versa. KISS means simple for the people who have to maintain it.
2. Some problems are essentially complex. Distributed consensus, cryptography, concurrent memory models — no amount of KISS will collapse these into trivial code. Respect teslers-law (conservation of complexity): the complexity must live somewhere.
3. “Simple” can be a cover for under-thought. A single-file script can be simpler than a modular system and also much harder to change. KISS is not “write less code”; it’s “write code that’s easier to reason about.”

Sources

• source—laws-of-software-engineering — in the Design cluster.
• Kelly Johnson (Lockheed Skunk Works) — originated the principle in aircraft engineering.