DRY, KISS and YAGNI: Three rules of thumb for simple code

In short: Three mnemonics: don’t repeat yourself (DRY), keep it simple (KISS) and don’t build anything in advance (YAGNI).

In more detail: The abbreviations condense experience from many projects. They complement each other but can also contradict each other. They are rules of thumb for decisions, not laws, and can be overdone.

In Depth

DRY: Don’t repeat yourself

Every piece of knowledge should have exactly one unambiguous place in the system. If a rule (for example the VAT rate) is copied in five places, all five must be found on a change, and one is forgotten. Instead of copying, put the code into a function or constant. Careful: DRY means knowledge, not coincidentally similar text. Two pieces of code that look the same but change for different reasons should not be forced together. A wrong abstraction is more expensive than a bit of duplication.

KISS: Keep it simple, stupid

The simplest solution that solves the problem is usually the best. Simple code is easier to read, test and change. Warning signs: deeply nested conditions, “clever” one-liners, patterns without recognisable benefit. Ask yourself: will a new team member understand this in a minute?

YAGNI: You aren’t gonna need it

Build features only when you actually need them. Settings, extension points and parameters built as a precaution cost time, must be tested and usually do not fit the real need later anyway. That does not forbid planning: a clean structure makes later extensions easy without building them yet.

Interplay

An example: two pages need a similar table. Building a huge, configurable table framework straight away violates YAGNI and KISS. Copying once and merging at the third occurrence (“rule of three”) is often a good middle path. Good refactoring first makes code work and then makes it simple.

See also: Clean code, Refactoring, SOLID principles