KISS · DRY · YAGNI
KISS · DRY · YAGNI
These three acronyms are often cited together as software design principles. Their origins and meanings differ slightly, and some interpretations even conflict. This article covers the origin, intent, and frequently confused cases of each.
1. KISS — Keep It Simple, Stupid
A motto established by US aerospace engineer Kelly Johnson at Lockheed Skunk Works in the 1960s. The interpretation is not "keep it simple, stupid (you idiot)" but rather "design aircraft so that an average mechanic can repair it in the field with only basic tools". The accepted reading is that the second S is an adjective describing the result, not an insult aimed at a person.
Translated to software, it means:
- A system should not become more complex than necessary.
- When two designs produce the same result, the simpler one usually lives longer.
- "Simple" is not the same as "few features". A simple system can still have rich functionality.
2. DRY — Don't Repeat Yourself
From Andy Hunt and David Thomas's 1999 book The Pragmatic Programmer, around page 26:
"Every piece of knowledge must have a single, unambiguous, authoritative representation within a system."
It is often forgotten that the original phrase says "knowledge". DRY is closer to "don't write the same fact in many places" than to "merge code that looks similar".
Frequently confused cases:
- Two functions whose code happens to look similar but represents different facts (= business rules). Merging them drags one along when the other changes. In Sandi Metz's words, "duplication is far cheaper than the wrong abstraction".
- The same constant (e.g. tax rate, API URL) scattered across multiple files. This is a clear case where DRY applies. Define it in one place and import.
It is commonly said that applying DRY based on "the knowledge is the same" rather than "the code pattern is the same" is the safer guide.
3. YAGNI — You Aren't Gonna Need It
A motto that grew out of the Extreme Programming (XP) camp. Often cited as established by Ron Jeffries. The intent is simple:
Don't build features that aren't needed by the current user story right now.
Pre-building abstractions or interfaces that "might be needed later" carries these costs:
- Maintenance starts the moment you build it.
- There is no guarantee the abstraction will exactly match the real future requirement.
- The pressure of "we built it, so let's use it" creates wrong coupling.
Martin Fowler organized these costs into four (cost of building, cost of carry, cost of repair, cost of delay) in his 2015 article "Yagni". YAGNI does not mean rejecting abstractions forever, but delaying the timing of abstraction.
4. Cases where the three principles conflict
The three principles often point in the same direction, but they also conflict:
- DRY vs YAGNI — Merging the similar parts of two functions into an abstraction is DRY, but if the abstraction is not needed right now, it violates YAGNI.
- KISS vs DRY — The choice of leaving slight duplication for simplicity conflicts with the choice of adding an abstraction layer to remove duplication.
In these cases, neither side is absolutely right. The suitable choice depends on change frequency, code lifespan, and team size — a common observation. Generally, "duplication is easy to merge later, but a wrong abstraction is hard to undo".
5. Pitfalls beginners often face
Merging two pieces of code based on pattern matching alone, then watching if-else branches multiply endlessly when one side's business rule changes.
Introducing an interface for future extensibility, only to find a year later that there is still only one implementation.
Misreading "keep it simple" as "skip validation and error handling" — KISS calls for simplicity that aids reasoning, not abandoning robustness.
Closing thoughts
These three acronyms are short, but to grasp their real meaning it is worth looking at their origins once. KISS is field repair by a mechanic, DRY is single representation of knowledge, YAGNI is delaying the timing of abstraction. The single sentence "the wrong abstraction is more expensive than duplication" balances all three well.
Next
- ssot-everywhere
- folder-as-contract
The Pragmatic Programmer · Martin Fowler Yagni · Wikipedia KISS principle · Sandi Metz The Wrong Abstraction · c2 wiki YouArentGonnaNeedIt · Hillel Wayne Empiricism and Knowledge for reference.