KISS: keep it simple

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.
• 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, and sometimes argues against an over-eager application of DRY.