DRY: Don't Repeat Yourself

THE MENTAL MODEL: Don't Repeat Yourself (DRY) is a principle that every piece of knowledge within a system should have a single, unambiguous, authoritative representation. It's not just about avoiding duplicate code, but about avoiding duplicate information, whether that's logic, data, or configuration.

HOW IT WORKS: When you identify repetition, you replace it with an abstraction. For repeated logic, you might create a function or a class. For repeated data, you might use a constant or a configuration file. The goal is to create a single source of truth. If that piece of information ever needs to change, you only have to update it in one place, and the change propagates throughout the system automatically. This reduces the risk of bugs caused by inconsistent, out-of-sync copies.

WHEN TO USE IT: DRY is fundamental to maintainable software. Use it for: first, business logic that appears in multiple places, like a sales tax calculation; second, configuration values like API endpoints or timeout settings that are used by different modules; third, user interface elements that should be consistent, like a standard button component.

WHEN NOT TO USE IT: The primary footgun is applying DRY too aggressively, leading to premature or incorrect abstractions. Sometimes two pieces of code look identical by coincidence but represent different business concepts. Forcing them into a single abstraction means a change required for one concept will unintentionally and incorrectly affect the other. A common heuristic is "Write Everything Twice" (WET). Wait for the third instance of repetition before creating an abstraction to ensure you've identified a true pattern.

ONE CANONICAL EXAMPLE: Imagine an application with user email validation. The same validation logic is needed on the frontend registration form (in JavaScript), on the backend API server (in Python), and in a separate data-cleaning script. Instead of writing the validation regex in three different places and languages, a DRY approach would be to define it once, perhaps in a shared configuration file or a dedicated validation service that all three components can query. If the email rules change, you update it in one place.