DRY, KISS, and YAGNI - Low-Level Design Guide

Overview

DRY (Don't Repeat Yourself): every piece of knowledge should have a single authoritative representation. If the tax rule lives in three places, a change will eventually miss one. KISS (Keep It Simple, Stupid): prefer the simplest design that works. YAGNI (You Aren't Gonna Need It): do not build features or abstractions until they are actually needed.

These principles balance each other against over- and under-engineering. DRY is about duplicated knowledge, not identical-looking code; two similar lines that change for different reasons should stay separate. KISS and YAGNI prevent speculative abstractions, while DRY and SOLID prevent tangled duplication.

Packing for a trip

DRY: keep one master packing list instead of three that drift apart. KISS: pack a simple outfit system rather than a complicated one. YAGNI: do not pack a snowsuit for a beach trip 'just in case'.

When to use it

Reviewing designs for over-engineering or copy-paste logic.
Deciding whether to introduce an abstraction now or later.
Interview discussions about trade-offs and pragmatism.

Where it shows up in interviews

Over-engineering check

Recognize it when: interviewer asks 'is this needed?'

Design a simple URL shortener class
Design a to-do app

Duplicated rules

Recognize it when: same business rule in several classes.

Refactor pricing logic
Refactor validation rules

Where it is used in real software

The Pragmatic Programmer

Introduced DRY as 'every piece of knowledge must have a single, unambiguous representation'.

Extreme Programming

YAGNI came from XP practice: implement only what current stories need.

Rule of three

Many teams refactor to a shared abstraction only when duplication appears the third time.

Key terms

Knowledge duplication: The same rule or fact encoded in multiple places.
Incidental duplication: Similar code that represents different concepts.
Speculative generality: Abstractions for hypothetical future needs.
Rule of three: Abstract after the third repetition.

How it works, step by step

1
Spot duplicated knowledge
Same rule, constant, or validation in several places.
2
Check it changes for the same reason
If yes, unify; if not, keep separate.
3
Extract the single source
A function, constant, value object, or config.
4
Question every abstraction
Is there a current requirement or second implementation?
5
Prefer the simplest thing that works
Refactor when requirements actually change.

Applying the principles

Examples from a shop codebase

Situation	Principle	Action
Tax rate 0.18 hard-coded in 4 files	DRY	One TaxPolicy or config value
Plugin system for one payment provider	YAGNI	Direct implementation behind an interface
Generic rule engine for 2 discount types	KISS	Two small classes
Similar validation for User and Product names	DRY? No	Keep separate: rules change independently

NOWSituation: Tax rate 0.18 hard-coded in 4 files | Principle: DRY | Action: One TaxPolicy or config value

Duplication of knowledge is costly; duplication of shape is often fine. Build for today's requirements with clean seams for tomorrow.

Implementation

1// DRY: one source of truth for a business rule2export const FREE_SHIPPING_THRESHOLD_CENTS = 5_000;3export const qualifiesForFreeShipping = (subtotalCents: number) => subtotalCents >= FREE_SHIPPING_THRESHOLD_CENTS;4 5// Used by cart UI, checkout, and email templates alike6function shippingCost(subtotalCents: number) {7  return qualifiesForFreeShipping(subtotalCents) ? 0 : 599;8}9 10// KISS / YAGNI: a plain function instead of a speculative framework11// Avoid: class ShippingStrategyFactoryProvider { ... } when one rule exists today.

Complexity and performance

Change cost with duplicationO(copies)

And risk of missing one.

Cost of speculative abstractionOngoing complexity

Paid even if never used.

Trade-offs

DRY vs coupling

Merging code used by unrelated features couples them; the wrong abstraction is worse than duplication.

YAGNI vs known requirements

YAGNI does not mean ignoring requirements that are confirmed and imminent; leave clean extension points.

Variants and related techniques

WET (Write Everything Twice)

Tolerate duplication until the pattern is clear.

AHA (Avoid Hasty Abstractions)

Prefer duplication over the wrong abstraction.

Common mistakes

Merging similar-looking code with different reasons to change.
Fix: Keep it separate until it truly represents the same knowledge.
Building generic frameworks in interviews.
Fix: Solve stated requirements cleanly; mention how you would extend.

Interview questions

Is all duplication bad?

No. Duplicated knowledge (the same business rule) is bad. Code that looks similar but represents different concepts that change independently should often stay separate.

How do YAGNI and OCP coexist?

Apply OCP where variation is known or recurring; YAGNI warns against creating extension points for speculative variation. Refactor toward OCP when the second variant appears.

Practice problems

Problem	Difficulty	What it trains
Find duplicated rules in a checkout codebase	Easy	Single source of truth.
Simplify an over-engineered design	Medium	KISS and YAGNI.