When Knowing 7 Development Principles Still Fails: How to Apply DRY, KISS, YAGNI, POLA, and More

Understanding versus applying principles – The author repeats that the problem is not a shortage of principles but a mis‑understanding of them; a correct understanding still requires a decision framework to know when a principle should guide a change.

DRY – When to tolerate duplication

DRY originates from The Pragmatic Programmer (1999) and means “a single authoritative definition of knowledge”. The author proposes a three‑question framework:

Do the two code blocks express the same knowledge?

If one changes, must the other change synchronously?

Is the abstracted interface easier to understand than the duplicated code?

If any answer is “no”, duplication is acceptable. Example:

sendEmail(type, to, welcomeText, resetToken, securityTip)
// type="register" → only welcomeText used, other params null
// type="reset"   → only resetToken/securityTip used, welcomeText null

Better approach (tolerating duplication):

sendWelcomeEmail(to, welcomeText)
sendResetEmail(to, resetToken, securityTip)

Thus “repetition is debt, abstraction is tax” – choose the cheaper debt.

KISS – Simplicity as low cognitive load

KISS (Keep It Simple, Stupid) stems from Kelly Johnson’s 1960s design rule at Lockheed. Simplicity is defined as low cognitive complexity, not merely fewer lines of code. The author distinguishes cyclomatic complexity (path count) from cognitive complexity (understanding difficulty). Example of a nested ternary shows low cyclomatic but high cognitive cost.

Rule of thumb: a reader should grasp a function’s intent within 30 seconds without consulting comments. If they can, the code is simple even with high cyclomatic complexity.

YAGNI – Avoid coding for imagined futures

YAGNI (“You Aren’t Gonna Need It”) was coined by Kent Beck during the C3 project. The key distinction is between premature design (acceptable) and premature coding (waste). Decision question: “If this requirement never arrives, is the code pure waste?”

Example of a strategy interface:

interface PaymentStrategy { pay(); }
// Define only current strategies – allowed
// Adding empty future implementations – not allowed

Thus, define extensible interfaces now, but defer concrete implementations until needed.

POLA – Code should behave as its name suggests

Principle of Least Astonishment (POLA) dates back to 1984 and stresses that behavior must match expectations. The author provides an “expectation consistency check”:

Can the caller predict the behavior from the function name?

Does the return type match intuition?

Are side‑effects within expectations?

Violations (e.g., a query method that also updates state) are fixed by separating query and command:

User getUserById(String id) { return userDao.findById(id); }
void updateLastLogin(String id) { … }

Boy Scout Rule – Incremental improvement

Robert C. Martin cites the rule in Clean Code : each commit should leave the code a little better. A practical checklist includes:

Rename an ambiguous variable

Extract a long function

Delete dead code

Add a missing type annotation

Fix an obvious code smell

No extra planning or review is required – just a 30‑second scan before committing.

Fail Fast – Expose errors early

Jim Shore (2004) defines Fail Fast as shortening the time between error occurrence and detection. Three implementation “weapons” are described:

Defensive programming : validate inputs at entry and throw exceptions immediately.

Contract design : state pre‑conditions, post‑conditions, and invariants.

Assertions : use assert during development to catch impossible states.

Production uses defensive checks; development adds assertions for diagnosis.

Separation of Concerns – Split by change reason

Edsger Dijkstra’s 1974 paper introduced the idea of separating concerns based on change frequency, reason, and impact. The author suggests a “change‑frequency analysis”:

Different change cadence (weekly vs yearly)

Different drivers (business rule vs technical upgrade)

Different impact scope (module‑local vs system‑wide)

Thus, avoid splitting by technical layer alone; split by why the code changes.

Balancing the tensions

The seven principles interact with trade‑offs: DRY reduces duplication but can raise cognitive cost; KISS reduces cognitive load but may increase duplication; YAGNI avoids premature code but requires good interface design; POLA warns against over‑abstracted functions that surprise callers. The author encourages developers to build their own judgment frameworks for each principle and to make balanced decisions when they conflict.

Finally, the article invites readers to pick a principle they thought they understood, write their own decision framework, and apply it in the next code review to move from “knowing the name” to “using it correctly”.