DRY, KISS and YAGNI without dogma

DRY (“don’t repeat yourself”), KISS (“keep it simple”) and YAGNI (“you aren’t gonna need it”) are the three slogans quoted most often in design discussions, and they are misused just as often. In the forms their sources give them, each is precise. DRY is about knowledge, not about text. Simple means the fewest elements that pass the tests and show their intent, not the fewest lines. YAGNI means building what today’s requirements ask for while keeping the code easy to change. This lesson runs an example of each, including the bug that the most common misuse of DRY causes.

DRY is about knowledge, not text

Andy Hunt and Dave Thomas named the principle in The Pragmatic Programmer, and defined it like this:

Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

In the book’s second edition they say that many readers of the first took DRY to mean “don’t copy-and-paste lines of source”, and that this is only a small part of it. Their test is about change: when one fact changes, do you have to make that change in several places, perhaps in several formats? Then the fact is duplicated. A college library allows each member three books at a time. If can_borrow(), borrow() and the holdings report each contain the number 3, the rule exists three times. When the library allows four, someone must find all three copies, and the one they miss gives a member a fourth book at the desk while the report still says “3 of 3”.

Knowledge also hides outside code. A limit stated by hand in a help page and enforced in a function is one fact in two places, and so is a database column added by hand both to a table and to the class that maps it. The cure is the same each time: one authoritative place, a constant, a table or a schema, and everything else derived from it or reading it.

Code that only looks the same

The opposite mistake is to treat look-alike code as duplication. The same college charges a late fine in two places. The library charges for books returned late: two days free, then 5 a day. The sports room charges for kit, such as bats and rackets, returned late: two days free, then 5 a day. Someone notices the two identical functions and merges them into one late_fine() “to stay DRY”. Then the library decides that no book should cost more than 50 in fines, and the developer adds the cap to the shared function. Each owner’s checks, run against the merged design and against two separate functions:

"""Each owner's checks, run against both designs after the library capped book fines at 50."""

import fines_merged
import fines_separate

CHECKS = [
    ("library", "book_fine", 30, 50),  # capped: 28 chargeable days would be 140
    ("library", "book_fine", 5, 15),
    ("sports", "kit_fine", 30, 140),  # the sports room never asked for a cap
    ("sports", "kit_fine", 5, 15),
]

for design in (fines_merged, fines_separate):
    print(f"{design.__name__}:")
    for owner, function, days, expected in CHECKS:
        got = getattr(design, function)(days)
        verdict = "ok" if got == expected else f"WRONG, the {owner} rule says {expected}"
        print(f"  {owner:8} {function}({days}) = {got:<4} {verdict}")

fines_merged:
  library  book_fine(30) = 50   ok
  library  book_fine(5) = 15   ok
  sports   kit_fine(30) = 50   WRONG, the sports rule says 140
  sports   kit_fine(5) = 15   ok
fines_separate:
  library  book_fine(30) = 50   ok
  library  book_fine(5) = 15   ok
  sports   kit_fine(30) = 140  ok
  sports   kit_fine(5) = 15   ok

"""The college's two late fines after someone merged them "to stay DRY", and then applied the library's new cap."""

FREE_DAYS = 2
PER_DAY = 5
CAP = 50  # the library's new rule: no book costs more than 50 in fines


def late_fine(days_late):
    """Used by the library for books and by the sports room for kit."""
    return min(CAP, max(0, days_late - FREE_DAYS) * PER_DAY)


def book_fine(days_late):
    return late_fine(days_late)


def kit_fine(days_late):
    return late_fine(days_late)

"""The same two fines kept apart, because they belong to two owners who change them for their own reasons."""

# The library's rule, owned by the librarian.
BOOK_FREE_DAYS = 2
BOOK_PER_DAY = 5
BOOK_CAP = 50  # the library's new rule


def book_fine(days_late):
    return min(BOOK_CAP, max(0, days_late - BOOK_FREE_DAYS) * BOOK_PER_DAY)


# The sports room's rule, owned by the sports teacher. It looks the same as the library's old rule, by coincidence.
KIT_FREE_DAYS = 2
KIT_PER_DAY = 5


def kit_fine(days_late):
    return max(0, days_late - KIT_FREE_DAYS) * KIT_PER_DAY

The library’s checks pass in both designs. In the merged one, a kit returned 30 days late now costs 50 instead of 140, a change the sports room never asked for and will not notice until someone complains. The two functions were never one piece of knowledge: they belong to two owners, who change them for their own reasons, as the lesson on the Single Responsibility Principle put it. The Pragmatic Programmer makes the same point with two validation functions whose bodies happen to match: the code is the same, the knowledge is not, and the match is a coincidence.

The wrong abstraction

Sandi Metz wrote that “duplication is far cheaper than the wrong abstraction”, and described how such an abstraction grows. Someone extracts the duplicated code into a shared function. Later a new case almost fits it, so the function gets a parameter and a condition. Then another case, another parameter, another condition, until nobody can read it or change it safely. Her way out is to go back: copy the shared code into each caller again, delete the parts each caller does not use, and only then look for what is really shared.

A guideline that prevents most of this is the rule of three, which Martin Fowler’s book Refactoring credits to Don Roberts: the first time you write something, just write it; the second time, notice the repetition and write it again anyway; the third time, extract it. It is a heuristic, not a law. Two copies cost little, and waiting shows whether they change together. If they do, you have found one piece of knowledge and can give it one home; if they drift apart, you have saved yourself a function with a flag.

KISS: fewer concepts, not fewer lines

“Keep it simple” is easy to agree with and hard to apply, because it does not say simple for whom. Kent Beck’s four rules of simple design, which Martin Fowler summarises as passes the tests, reveals intention, no duplication and fewest elements, give it an order of priority. The code first has to work. Then a reader must be able to see what it is for; a clever one-line comprehension that takes a minute to decode loses to a plain loop here. Then no fact may be stated twice, which is DRY. Only last come the fewest classes, functions and names.

That order settles most arguments. Shorter is not simpler if it hides intent, and a design with extension points that nothing uses fails the last rule however clean each piece looks. The simplest design is the one with the fewest concepts a reader has to learn to trust it.

YAGNI: build what is needed now

The canteen at the same college has one pricing rule: lunch costs 10 % more from 12:00 to 14:00. One version of the code expects many more rules one day, and builds a rule interface, a plugin registry, a configuration format and a pipeline that applies the configured rules in order. Another version is a function with an if. Both get the same six checks, and then this program measures them from their source:

"""Runs the same checks against both pricing modules, then measures each one's size from its source."""

import ast
from pathlib import Path

import plain
import speculative

CHECKS = [  # (base price in paise, hour) -> price in paise
    ((4000, 11), 4000),
    ((4000, 12), 4400),
    ((4000, 13), 4400),
    ((4000, 14), 4000),
    ((2550, 12), 2805),
    ((0, 13), 0),
]


def passes(module):
    return sum(module.price(*args) == expected for args, expected in CHECKS)


def size(module):
    source = Path(module.__file__).read_text(encoding="utf-8")
    tree = ast.parse(source)
    docstrings = set()
    for node in ast.walk(tree):
        if isinstance(node, (ast.Module, ast.ClassDef, ast.FunctionDef)) and ast.get_docstring(node) is not None:
            first = node.body[0]
            docstrings.update(range(first.lineno, first.end_lineno + 1))
    code_lines = [
        number
        for number, line in enumerate(source.splitlines(), start=1)
        if line.strip() and not line.strip().startswith("#") and number not in docstrings
    ]
    classes = sum(isinstance(node, ast.ClassDef) for node in ast.walk(tree))
    functions = sum(isinstance(node, ast.FunctionDef) for node in ast.walk(tree))
    return len(code_lines), classes, functions


for module in (speculative, plain):
    print(f"{module.__name__}.py passes {passes(module)} of {len(CHECKS)} checks")
print(f"{'':16}{'lines of code':>15}{'classes':>10}{'functions':>11}")
for module in (speculative, plain):
    lines, classes, functions = size(module)
    print(f"{module.__name__ + '.py':16}{lines:>15}{classes:>10}{functions:>11}")

speculative.py passes 6 of 6 checks
plain.py passes 6 of 6 checks
                  lines of code   classes  functions
speculative.py               44         5         12
plain.py                      5         0          1

"""Canteen pricing, built for rules that might come one day: a plugin registry, rules read from configuration and a
pipeline that applies them in order. Only one rule exists: lunch costs 10 % more from 12:00 to 14:00."""

from abc import ABC, abstractmethod
from dataclasses import dataclass, field


@dataclass(frozen=True)
class PricingContext:
    base_paise: int
    hour: int
    extras: dict = field(default_factory=dict)


class PricingRule(ABC):
    @abstractmethod
    def applies(self, context: PricingContext) -> bool: ...

    @abstractmethod
    def adjust(self, price: int, context: PricingContext) -> int: ...


class RuleRegistry:
    def __init__(self):
        self._rules = {}

    def register(self, name):
        def decorator(cls):
            self._rules[name] = cls
            return cls

        return decorator

    def build(self, config):
        return [self._rules[entry["rule"]](**entry.get("options", {})) for entry in config]


registry = RuleRegistry()


@registry.register("peak-hours")
class PeakHourRule(PricingRule):
    def __init__(self, start=12, end=14, percent=10):
        self.start, self.end, self.percent = start, end, percent

    def applies(self, context):
        return self.start <= context.hour < self.end

    def adjust(self, price, context):
        return price + price * self.percent // 100


class PricingPipeline:
    def __init__(self, rules):
        self._rules = list(rules)

    def price(self, context):
        price = context.base_paise
        for rule in self._rules:
            if rule.applies(context):
                price = rule.adjust(price, context)
        return price


CONFIG = [{"rule": "peak-hours", "options": {"start": 12, "end": 14, "percent": 10}}]
_pipeline = PricingPipeline(registry.build(CONFIG))


def price(base_paise, hour):
    return _pipeline.price(PricingContext(base_paise, hour))

"""Canteen pricing for the one rule that exists: lunch costs 10 % more from 12:00 to 14:00."""

PEAK_HOURS = range(12, 14)


def price(base_paise, hour):
    if hour in PEAK_HOURS:
        return base_paise + base_paise // 10
    return base_paise

Both pass every check. One needs 44 lines of code, 5 classes and 12 functions to do what the other does with 5 lines and one function. Martin Fowler’s note on YAGNI, a practice from Extreme Programming, names what the extra code costs. The cost of build is the work spent on it, wasted if the predicted rules never come. The cost of delay is the needed features that waited while it was built. The cost of carry is the extra complexity that every later change has to work around, even if the prediction was right. The cost of repair comes when the rules do arrive and turn out different from the guess, so the framework has to be reworked anyway.

Fowler is careful about what YAGNI does not cover: it never argues against making code easier to change. Refactoring, tests and small, clear units are what make it safe to wait. When the second pricing rule arrives, the plain version turns into a seam in a few minutes, as the lesson on the Open/Closed Principle did for vehicle fees. And when a requirement does say that rules will change often, for example that the canteen committee sets them every month without a release, the registry is no longer speculation and earns its place.

Using the three together

The three pull in the same direction most of the time: one home for each fact, as few concepts as the requirements allow, and nothing built for a guessed future. When they disagree, for example a seam that YAGNI calls premature and a change that the requirements say is coming, the next lessons of this module show how to argue the case.

Interview questions

Warm-up (fresher to mid level): what does DRY mean, exactly, and what does it not mean? DRY, from The Pragmatic Programmer, says that every piece of knowledge should have a single, unambiguous, authoritative representation in a system: a business rule, a limit or a data format should live in one place that everything else reads or derives from. The test is a change: if one fact changing forces edits in several places, the fact is duplicated, whether the copies are in code, documents or schemas. DRY does not mean that similar-looking code must be merged. Two functions with the same body can represent two different rules with different owners, and merging them couples those owners, so a change for one breaks the other. Duplicated text is a reason to ask whether the knowledge is shared, not a reason to extract a function.

Key takeaways

• DRY is about knowledge: one fact, one authoritative place. Test it by asking how many places one change touches.
• Identical code can be two pieces of knowledge; merging two owners’ rules couples them and breaks one when the other changes.
• The wrong abstraction costs more than duplication. Undo it by inlining, and wait for a third case before extracting.
• Simple means Beck’s order: passes the tests, reveals intention, no duplication, fewest elements.
• YAGNI: build for today’s requirements, keep the code easy to change, and count the costs of build, delay, carry and repair before building for a guess.