When we hear the term software design, it often sounds like something very advanced.
People start talking about architecture, scalability, patterns, maintainability, and a lot of other big words.
But in reality, good software design often starts with very small decisions.
Questions like:
- Should I repeat this logic?
- Am I making this solution more complex than needed?
- Am I building something I do not even need right now?
These small decisions matter a lot.
As I’ve been spending more time revisiting core software engineering concepts, I realized that before going deep into system design, it helps to understand a few simple principles that shape good code from the beginning.
Three of the most important ones are:
- DRY — Don’t Repeat Yourself
- KISS — Keep It Simple, Stupid
- YAGNI — You Aren’t Gonna Need It
These are not frameworks.
They are not strict rules either.
They are practical principles that help us write code that is easier to understand, maintain, and extend.
In this post, let’s understand these three principles in simple words with JavaScript examples.
Why these principles matter
When a project is small, even messy code can feel manageable.
But as the project grows, the same issues start showing up again and again:
- the same logic appears in multiple places
- simple features become harder to change
- unnecessary abstractions make code harder to read
- “future-ready” features increase complexity without solving a real problem
That is where design principles help.
They do not guarantee perfect code.
But they do help us avoid many common mistakes.
And that is a big part of writing maintainable software.
1. DRY: Don’t Repeat Yourself
What DRY means
DRY means that a piece of logic or knowledge should have one clear source of truth.
In simple words:
If the same logic is repeated in multiple places, it becomes harder to maintain.
Because later, when the logic changes, you may need to update it everywhere.
And if you miss even one place, bugs start appearing.
A simple example without DRY
const length1 = 10;
const width1 = 5;
const area1 = length1 * width1;
console.log("Area 1:", area1);
const length2 = 8;
const width2 = 4;
const area2 = length2 * width2;
console.log("Area 2:", area2);
This works.
But the area calculation logic is repeated.
Right now, it may not look like a big issue.
But if you later want to add validation, change the formula, or reuse the same logic in more places, this duplication becomes a maintenance problem.
A better DRY version
class AreaCalculator {
static calculateArea(length, width) {
return length * width;
}
}
const area1 = AreaCalculator.calculateArea(10, 5);
const area2 = AreaCalculator.calculateArea(8, 4);
console.log("Area 1:", area1);
console.log("Area 2:", area2);
Now the logic lives in one place.
That means:
- easier updates
- less duplication
- lower chance of inconsistency
This is the main benefit of DRY.
Where DRY helps in real projects
In real JavaScript applications, DRY often shows up in places like:
- form validation
- API handling
- utility functions
- repeated formatting logic
- repeated UI behavior
- business rules used in multiple places
For example, if multiple forms need the same email validation logic, it usually makes sense to extract that into a reusable function.
That way, if the validation rule changes later, you update it once.
When DRY is overused
This is where things get interesting.
Many developers learn DRY and then start extracting everything too early.
But just because two code blocks look similar does not always mean they should be merged.
For example:
function formatUserName(user) {
return `${user.firstName} ${user.lastName}`;
}
function formatProductName(product) {
return `${product.brand} ${product.title}`;
}
At first glance, both are “formatting names”.
But they serve different domains.
If we force them into one generic helper too early, we may make the code less clear.
So DRY is useful.
But premature abstraction is not.
A good rule is:
Avoid repeating true logic, but do not rush into creating shared abstractions too early.
2. KISS: Keep It Simple, Stupid
What KISS means
KISS means:
Use the simplest solution that clearly solves the problem.
In simple words:
Do not overcomplicate things.
Sometimes code becomes hard to read not because the problem is difficult, but because the solution is written in a more complicated way than necessary.
An unnecessarily complex example
Let’s say we want to check whether a number is even.
class NumberUtils {
static isEven(number) {
let isEven = false;
if (number % 2 === 0) {
isEven = true;
} else {
isEven = false;
}
return isEven;
}
}
This code works.
But it is doing too much for a very small task.
It uses:
- an extra variable
- an unnecessary
if...else - more lines than needed
That makes the code longer and slightly harder to read.
A simpler version
class NumberUtils {
static isEven(number) {
return number % 2 === 0;
}
}
This is much better.
Why?
Because it is:
- shorter
- clearer
- easier to understand at a glance
That is what KISS encourages.
KISS in everyday JavaScript code
KISS is very useful when writing:
- conditionals
- helper functions
- component logic
- state updates
- APIs
- class methods
For example, compare these two conditions:
if (!(user === null || user === undefined) && user.isActive === true) {
console.log("User is active");
}
and
if (user && user.isActive) {
console.log("User is active");
}
Both do the same job.
But the second version is cleaner and easier to read.
That is usually the better design choice.
Simple does not mean careless
This is important.
KISS does not mean:
- avoid structure
- ignore edge cases
- skip validation
- write everything in one function
- never create abstractions
Simple code is not lazy code.
Simple code is code that solves the problem without unnecessary mental overhead.
That is a big difference.
3. YAGNI: You Aren’t Gonna Need It
What YAGNI means
YAGNI means:
Do not build something until it is actually needed.
In simple words:
Avoid adding features just because you think they may be useful in the future.
This happens a lot during development.
We start with one requirement, then our mind jumps ahead:
- maybe later we will need categories
- maybe later we will need filters
- maybe later we will need version history
- maybe later we will need sync support
So we start designing for all of that from day one.
But many of those features never arrive.
And even if they do, they may come in a completely different form.
That is why YAGNI matters.
A simple example
Suppose the current requirement is only this:
- create a note
- view notes
That’s it.
But instead of building just that, we create a bigger system with support for:
- tags
- archived notes
- sharing
- version tracking
- cloud sync queues
Like this:
class NotesApp {
constructor() {
this.notes = [];
this.tags = new Map();
this.archivedNotes = [];
this.sharedNotes = [];
this.versionHistory = new Map();
this.syncQueue = [];
}
addNote(note) {
this.notes.push(note);
}
}
Most of this complexity is unnecessary if the product only needs basic notes right now.
A better version
class NotesApp {
constructor() {
this.notes = [];
}
addNote(note) {
this.notes.push(note);
}
getNotes() {
return this.notes;
}
}
This version is focused.
It solves the current problem.
And if new requirements come later, we can extend it then.
That is the spirit of YAGNI.
When YAGNI should not be applied blindly
Just like DRY and KISS, YAGNI is also not absolute.
Sometimes future requirements are not guesses.
Sometimes they are already confirmed.
For example, if your team knows that file attachments are definitely coming in the next sprint, it may be reasonable to prepare the design a little.
So YAGNI does not mean:
never think ahead
It means:
do not spend time building complexity for imaginary requirements
That is the important difference.
These principles are helpful, but not absolute
One of the most useful things to understand is this:
These principles can sometimes pull in different directions.
For example:
- DRY says avoid duplication
- KISS says keep things simple
But sometimes making code DRY too early creates an abstraction that actually makes the code harder to understand.
So what do we do?
We use these principles as guides, not as rigid laws.
The real goal is not to “apply a principle”.
The real goal is to write code that is:
- clear
- easy to change
- easy to test
- easier for other developers to understand
That is what good design is really about.
A simple way to remember all three
Here is the easiest way I remember them:
- DRY → don’t repeat real logic
- KISS → don’t make the solution harder than necessary
- YAGNI → don’t build for requirements that do not exist yet
That is it.
Small principles.
But very powerful when used well.
Interview-friendly explanation
If someone asks this in an interview, you can answer like this:
DRY means avoiding duplication by keeping one source of truth for logic.
KISS means choosing the simplest solution that works clearly.
YAGNI means not implementing features until they are actually needed.
These principles help improve readability, maintainability, and reduce unnecessary complexity in software systems.
That answer is short, clean, and strong enough for many interview situations.
Common mistake developers make
A very common mistake is thinking that better design always means:
- more abstraction
- more layers
- more generic code
- more future planning
But that is not always true.
Sometimes better design means:
- fewer moving parts
- smaller functions
- simpler conditions
- less abstraction
- fewer assumptions about the future
In many cases, simple and well-structured code is far better than clever code.
👋 About Me
Hi, I’m Saurav Kumar.
I enjoy learning, building, and writing about web development in simple words, especially topics that are useful for beginners and developers preparing for interviews.
Right now, I’m also focusing on improving my understanding of core concepts like JavaScript, OOP, system design, and software engineering fundamentals.
Let's connect!
🐙 GitHub: @saurav02022
💼 LinkedIn: Saurav Kumar
If you found this helpful, share it with a friend learning JavaScript — it might help them too.
Until next time, keep coding and keep learning 🚀
Top comments (0)