DRY, KISS and YAGNI are often presented as three separate principles. In my view, that misses the most important part.
Their real strength only appears once we start using them together.
It is not just about how we write code. It changes how we think about code, how we design applications and how much complexity we are willing to add to a system.
Simplicity as the foundation
KISS leads us towards simple, small and clearly named functional blocks. A function should do what its name says. If I cannot name it unambiguously, it may have too many roles.
In his rules of simple design, Kent Beck emphasises, among other things, revealing intent, removing duplication and keeping unnecessary elements to a minimum [1]. Simplicity is therefore not just about the number of lines, but above all about clarity.
KISS naturally helps DRY. In small, understandable blocks, repetition is visible. In The Pragmatic Programmer, Andy Hunt and Dave Thomas formulate DRY as the requirement that every piece of knowledge must have a single, unambiguous, authoritative representation within a system [2]. To me, that matters more than a simple “don't copy code”.
The goal, however, is not the smallest possible method or maximum reuse. Those are tools.
The goal is code that even someone who did not write it can understand.
We pay for complexity repeatedly
When I write code, I know the context. But a product lives for years, and most of the time it is read, debugged and changed by other people. That has a direct economic impact.
Complexity is not a one-off investment. It is a recurring cost.
We pay it during code reviews, onboarding, incidents, refactoring and the development of new features. And the longer the product lives, the more times we pay that bill.
YAGNI as protection against premature complexity
Martin Fowler describes YAGNI as the principle that a capability we merely presume the software will need in the future should not be built today [3]. In his text on simple design, he applies the same idea to frameworks, reusable components and flexibility built in advance: for such flexibility we pay a higher upfront cost in the expectation that it will pay off later [4].
Unused code is therefore not free. We have to understand it, test it and maintain it. Sometimes it can be cheaper to remove it and write it again only when it is actually needed.
Patterns are not decoration
Every abstraction has its cost. If we cannot say what specific complexity it removes or what value it brings, we probably do not need it yet.
I have seen a system where one design pattern started to be used almost everywhere. Gradually, strategies within strategies appeared, and on top of that their behaviour was driven by configuration in the database. During an incident, it was hard to understand what had actually been executed. Delivery slowed down, and estimates that used to work stopped matching reality.
Moreover, each additional abstraction is not a cost only for its author. Every new person who joins the product has to learn it. An architectural decision can thus affect the cost of development for years after the person who made it has left the team.
Simplicity as an investment
Instead of asking:
Which pattern can we use here?
I would rather ask:
What is the simplest solution that covers what we need today and still leaves us room to grow?
The goal is not code that shows how good we are. The goal is code that the next developer understands and can change safely.
That is why, for me, DRY, KISS and YAGNI are not three isolated rules. Together they create a way of thinking that helps keep complexity under control — technically, organisationally and economically.
Literature and sources
Sources verified on 4 October 2026.
[1] Beck, Kent. Extreme Programming Explained: Embrace Change. Addison-Wesley, 1999, in particular the Simple Design rules. Overview and discussion of the rules: Martin Fowler, Beck Design Rules, 2015.
[2] Hunt, Andrew; Thomas, David. The Pragmatic Programmer: Your Journey to Mastery, 20th Anniversary Edition. Addison-Wesley, 2019. Tip 15: DRY — Don't Repeat Yourself. The publisher's official list of tips at Pragmatic Bookshelf: pragprog.com/tips.
[3] Fowler, Martin. Yagni. 26 May 2015. MartinFowler.com.
[4] Fowler, Martin. Is Design Dead? — The Value of Simplicity. MartinFowler.com. The text discusses YAGNI, simple design and the cost of flexibility built in advance.