DRY, KISS, YAGNI

DRY — every fact has one home

DRY isn't really about lines of code looking the same. It's about knowledge. A single fact — a tax rate, a validation rule, the shape of a database row — should have one authoritative place it lives. When that fact changes, you change it in one spot, and the whole system stays correct.

The classic smell is the same calculation copy-pasted around the codebase:

// ⚠️ same tax knowledge, pasted in three places
function cartTotal(p: number)    { return p + p * 0.08; }
function invoiceTotal(p: number) { return p + p * 0.08; }
function receiptTotal(p: number) { return p + p * 0.08; }

The day the tax rate becomes 9%, you must remember all three spots. Miss one and your receipts disagree with your invoices. DRY says: give that fact one home.

const TAX_RATE = 0.08;                 // the single source of truth
function withTax(p: number) { return p + p * TAX_RATE; }
// cartTotal, invoiceTotal, receiptTotal all call withTax()

KISS — simple beats clever

Code is read far more often than it's written. KISS says the best version of a piece of code is the one the next person understands fastest — usually you, six months from now. A clever one-liner that saves three characters but takes a minute to decode is a bad trade.

// clever — correct, but you have to stop and decode it
const r = a.reduce((s, x) => s + (x.q ? x.q * x.p : 0), 0);

// simple — boring, and instantly readable
let total = 0;
for (const item of cart) {
  if (item.quantity) total += item.quantity * item.price;
}

Both compute the same total. The second one is longer and that's fine — anyone can read it at a glance, fix it under pressure, and trust it. KISS isn't 'write less code'; it's 'write code that's easy to understand.'

YAGNI — build for today, not for a guess

YAGNI fights the urge to add things 'just in case'. You're asked to save a user's name. The simple feature is one text field and a save. But it's tempting to also add multi-currency support, a plugin system, and full internationalization — because maybe the product will need them someday.

YAGNI says: don't. Every speculative feature is code you have to write, test, document, and maintain now, for a payoff that may never come. Most guessed-at futures never arrive, and when the real need shows up it's usually different from what you imagined — so you'd rebuild it anyway. Build the thing in front of you.

The tension: DRY vs. the wrong abstraction

Here is where these rules collide, and where good judgement matters most. Suppose two functions look 90% identical. DRY screams: merge them! So you extract a shared helper. Then the two callers slowly diverge — one needs an extra step, the other a special case. You add a flag parameter. Then another. Soon the 'shared' function is a maze of ifs that serves neither caller well. You optimized for DRY and destroyed KISS.

Reach for each rule when…

• DRY — when you catch yourself copy-pasting a fact (a rate, a regex, a config value, a row shape) into a second or third place. Give it one home before the copies drift apart.
• KISS — always, but especially when you feel the pull to be clever: a dense one-liner, a too-flexible config, a fancy pattern. Ask 'will the next reader get this fast?' If not, simplify.
• YAGNI — when you're about to add something 'just in case' for a future nobody has actually asked for. Build the requirement in front of you; revisit when the real need shows up.