# KISS: keep it simple

> Prefer the design with the fewest moving parts and concepts that meets the requirements; obvious code beats clever code.

Concept · Code design · https://levelcode.org/concepts/kiss

**KISS** — "Keep It Simple, Stupid", a phrase attributed to Lockheed engineer Kelly Johnson — says that most systems work best when kept simple, so simplicity should be a design goal and unnecessary complexity avoided. Johnson's version was concrete: a jet should be repairable in the field by an average mechanic with basic tools. The software equivalent: an average engineer on your team should be able to understand and fix the code during an incident.

## What "simple" means

Simple isn't the same as short or easy. Rich Hickey's distinction helps: **simple** means not intertwined — few parts, each doing one thing — while **easy** means familiar or close at hand. A one-line chain of clever operators can be short and familiar to its author while being anything but simple to verify.

Signs of avoidable complexity:

- A generic engine or framework built for one use case.
- Indirection without payoff: an interface with one implementation and no test that needs a fake; a factory that builds one type.
- Clever tricks — bit manipulation, dense functional chains, metaprogramming — where a plain loop would do.
- New infrastructure (a queue, a cache, another service) without a requirement that fails without it. See [when not to add infrastructure](https://levelcode.org/concepts/when-not-to-add-infrastructure).
- Configuration options nobody asked for.

## Applying it

- Prefer the boring solution; make it fancier only when measurement or a requirement demands it.
- Write code for the reader who will debug it at 2 a.m.
- When two designs meet the requirements, choose the one with fewer concepts to learn.
- Delete code, options and services that no longer earn their keep — removal is the purest simplification.

KISS doesn't mean ignoring real requirements: a payments system is necessarily more complex than a to-do app. It means the complexity should come from the problem, not from the solution. It pairs naturally with [YAGNI](https://levelcode.org/concepts/yagni), and sometimes argues against an over-eager application of [DRY](https://levelcode.org/concepts/dry).