When developing, it can strangely feel as though writing complicated code means you are doing a good job.
You add plenty of design patterns, stack abstraction layers, and define interfaces in advance because “we might need to extend it later.”
But when you open that code again a few years later, you realize that your future self is the one who has to suffer.
Today, let’s talk about KISS, the principle that takes the opposite approach.
To get straight to the point, KISS stands for “Keep It Simple, Stupid.” Taken literally, it means something like “Keep it simple, stupid.”
It is a design philosophy that systems work best not when they are made complex, but when they are kept simple.
Where did the KISS principle come from?
This phrase did not originally come from software.
It is attributed to Kelly Johnson, an aviation engineer at Lockheed in the United States during the 1960s. He designed the famous U-2 and SR-71 Blackbird reconnaissance aircraft.
Apparently, this is what Kelly Johnson asked of his team.
Build an aircraft that an ordinary mechanic can repair in combat using only basic tools.
No matter how brilliant the design is, it is useless if it cannot be repaired in the field.
That mindset carried over into software. No matter how clever the code is, it is not good code if teammates cannot read and fix it.
For context, “Stupid” does not mean calling developers stupid; it is closer to the nuance of “simple enough for anyone to understand.”
Moments when KISS breaks down in code
It sounds easy in theory, but what does it look like in real code? Here are a few patterns I often see.
1. A one-liner that looks impressive
// This makes you look smart
let result = arr.reduce([Int: Item]()) { $0.merging([$1.id: $1]) { _, new in new } }
// This is much easier to read
var result = [Int: Item]()
for item in arr {
result[item.id] = item
}The code above is short, but someone seeing it for the first time has to stare at it for a while. Anyone can understand the code below in three seconds.
2. Extensibility you will never use
For example, using both the factory pattern and the strategy pattern to create a single button. The concern is “What if we add more button types later?” But that “later” usually never comes.
3. The conditional maze
An if inside an if inside another if. Your mental stack overflows after only three levels of nesting. In cases like this, simply flattening the code with early returns can make it dramatically simpler.
Three practical criteria for following KISS
So when I write code, I use these three criteria.
| Criterion | Question |
|---|---|
| Explanation test | Can I explain this code to the colleague next to me in one minute? |
| Future test | Will I understand it immediately when I look at it six months from now? |
| Necessity test | Did I add this code because it is needed right now, or because I think I might use it someday? |
If even one answer is “no,” I reconsider whether there is a simpler approach.
The third one is especially important. It also aligns with the YAGNI (You Aren’t Gonna Need It) principle. KISS and YAGNI essentially work as a pair.
Simple is not the same as sloppy
There is one thing we should not misunderstand here.
KISS does not mean “write code without thinking.” In fact, it means the opposite.
Making things complicated is easy: you just attach everything that comes to mind. Making them simple is hard because you have to think carefully about what to remove.
Pascal left a famous line in a letter.
I would have written a shorter letter, but I did not have the time.
The same is true of code. Simple code is not the result of carelessness; it is the result of working to strip away complexity.
Summary
Here is the KISS principle in summary.
- Code is read far more often than it is written. Write it simply for the people who will read it.
- Do not add extensibility that is not currently needed. The situation you are worrying about is less likely to happen than you think.
- Simplicity is not a lack of skill; it is evidence of skill.
These days, the comment I leave most often in code reviews is, “Could this be simpler?” Surprisingly, that one question reduces both bugs and review time.
Can the colleague next to you understand your code in one minute? I hope you will ask yourself that question today.