Keep It Simple Stupid (KISS)

Build the simplest design that meets the real requirements, and add a moving part only when a measured problem asks for it.

Overview

KISS stands for Keep It Simple, Stupid. The blunt name carries one instruction: prefer the design with the fewest parts that still does the job. Every class, layer, pattern, service and configuration option is a thing someone must read, test, deploy and debug. A part that solves no present problem is pure cost.

Simple does not mean small or naive. A design can be simple and still handle a hard problem, because the difficulty comes from the problem, not from the design. Fred Brooks made this split in No Silver Bullet (1986): essential complexity is inherent in what the software must do; accidental complexity comes from how we chose to build it. KISS is the discipline of keeping the accidental part near zero.

Essential versus accidental

Essential — The problem itself: the rules, the data, the relationships — No; you can only model it clearly — Tax law has many cases; a scheduler must handle conflicts
Accidental — Our choices: tools, layers, patterns, indirection — Yes; that is what KISS targets — A factory for a class with one implementation; five services where one would do

What complexity costs

Every part costs at every stage of its life, not only when it is written.

Reading — One more thing to understand before you can change anything nearby
Testing — More paths, more mocks, more setup
Debugging — One more place the bug could be, one more hop in the stack trace
Operating — One more thing to deploy, monitor and keep patched
Changing — The part encodes an assumption; when the assumption changes, the part must too

Simple in code

In code, KISS usually means fewer layers of indirection. A common smell is a pattern applied to a problem with one case: a strategy interface with one strategy, a factory that only ever makes one class, a configuration system larger than the thing it configures.

An interface with one implementation and no test double — The class itself
A factory that always returns the same class — The constructor
A base class with one subclass — One class
A config option nobody sets — A constant
A pipeline of small functions for a three-line task — The three lines

That one function does the whole job. A version with an OfferSelector interface, a CheapestSelector class and a SelectorFactory would do the same job with three more names to learn. Add those only when a second selection rule really arrives.

Simple in system design

The same rule applies to architecture. Start with one deployable and one database when the requirements allow it, and add a cache, a queue, a second service or a shard when a stated requirement or a measurement asks for it. Say the trigger for each addition out loud; that is what shows judgment.

A cache — A measured hot read path, and the data tolerates being stale
A queue — Work that can be done later, or a producer faster than its consumer
A second service — A part that must scale, deploy or fail independently of the rest
Sharding — One database can no longer hold the data or the write load
An event log — Several consumers need the same history of changes

What you will be able to do

Separate the essential complexity of a problem from the accidental complexity of a design.
Name the ongoing costs of an extra part, not only the cost of writing it.
Recognize the common over-engineering smells in code and simplify them.
Start a system design from the simplest shape and justify each addition with a trigger.
Answer follow-ups on extensibility, technical debt and when complexity is worth it.

Interview questions

How do you balance KISS with the need to extend the design later?
What are the signs that a design is more complex than it needs to be?
How does KISS apply in a coding interview?
Show a design pattern used where it was not needed, and the simpler version.
What is the relationship between KISS and technical debt?