Lesson 0002 · Core Designer · Module 1

SRP, DRY, KISS, YAGNI in Context

These four are quoted as rules and violated as rules. The skill is reading them as forces: each names a failure mode, and each can be wrong.

Mission tie-in: AI will happily generate code that "follows the rules" while violating the point. Understanding the forces is what lets you keep control of AI output instead of accepting its letter.

Knowledge: forces, not rules

SRP — one reason to change

The unit is the reason to change, not the method. "We must edit this class because tax rules changed" and "…because we switched databases" — two reasons in one class is the failure. A class with twenty methods but one change source is fine; a class with two methods and two change sources is not.

DRY — once and only once, per unit of knowledge

DRY targets knowledge, not text. These two functions are identical today — and encode different knowledge:

def fee_for_bank_transfer(amount: Money) -> Money:
    return amount * Decimal("0.01")   # bank fee, set by our bank

def fee_for_wire_transfer(amount: Money) -> Money:
    return amount * Decimal("0.01")   # wire fee, set by the clearing house

Both compute 1% today. Merge them into one fee(amount) and the next time one fee changes, you will silently charge the other's customers the wrong amount. That is false DRY — deduplication that creates coupling between things that will diverge. The two fees changing together twice is what earns the merge (the rule of three).

KISS and YAGNI — the cost of complexity

KISS: prefer the least complex solution that meets the requirement. YAGNI: do not build capability with no evidence of need. Both are about unpaid tax: every generality, hook, and abstraction layer is paid for on every future read of the code, whether it's used or not.

† The expensive combination: YAGNI in the present ("too complex to build now") + KISS misread as "shortest code". Shortest is not simplest — a clear twenty-line function beats a clever five-liner.

The context is the whole story: a hook is YAGNI in a two-month project and common sense in a platform other teams will build on. The same line of code can be a violation and a virtue in two codebases.

Field notes · what it looks like in real code

You see this	What it costs	The move
`def fee(amount, kind)`	A `kind` flag is two facts pressed into one function.	Keep two functions until a third change moves both.
OrderData + OrderLogic	SRP applied by shape, not by change source — one force, two files.	Merge them back; split only where the forces differ.
**kwargs three layers deep	KISS misread as “less typing”: the contract disappeared.	Name the parameters at every layer.
strategy= with one implementation	YAGNI: a hook paid for on every read, used by nobody.	Delete the hook; add it when case two arrives.

Skill: judge the application, not the principle

Two systems charge the same 5% fee today. Extracting one shared function is:

A class has ten methods but exactly one reason to change. SRP says:

"We might need multi-currency later" — a price field with a currency enum added now. This is:

Practice on your own code

Find one place where a principle was applied as a rule — a shared helper that two things were forced into, a class split "to follow SRP", a generality built "just in case". Name the force it ignored.

Reveal: a worked judgment

An AI assistant refactors a file and reports: "Extracted get_price() shared by sales and returns, following DRY." Look closer: sales prices include VAT; return prices are ex-VAT. The shared helper is false DRY — the moment VAT rules change, returns pricing changes too. The right move is to keep two functions and one documented fact: these rates are set by different policies.

Your win

You can now apply the four principles as a judge, not an executor: for any "violation," name the force it actually threatens — and spot the rule-following that quietly does damage.

Read and watch deeper

Clean Architecture, Martin — ch. 7 "SRP: The Single Responsibility Principle": the reason-to-change definition.
The Pragmatic Programmer, Hunt & Thomas — the DRY chapter and "The Rule of Three".
A Philosophy of Software Design, Ousterhout — ch. 11 "Design It Twice" and the discussion of complexity in ch. 2: KISS made concrete.
Watch: ArjanCodes YouTube — search "7 principles of software design" for the source framing of these four.
Reference: Design Principles — all nineteen, each with the way it fails when followed as a rule; and the glossary on false DRY and the rule of three.

Stuck on a judgment call? Ask your agent-teacher: paste the code and the claimed principle, and it will help you name the force actually at stake.

Mark lesson complete