DRY Principle

DRY, or "Don't Repeat Yourself," is often misapplied as a rule against similar-looking code, but Milan Jovanovic's reading emphasizes the original Pragmatic Programmer formulation: every piece of knowledge should have one authoritative representation in a system. The important unit is not syntax; it is the domain fact or rule that must change together.^{source: milan-jovanovic-dry-misunderstood-2026.md}

The article's central distinction is between duplicated code and duplicated knowledge. Two validators, data structures, or modules can look identical while representing different concepts with different futures. If they are abstracted only because they currently share shape, the abstraction couples unrelated ideas and later attracts boolean flags, optional behavior, generic helper names, and fear around change.^{source: milan-jovanovic-dry-misunderstood-2026.md}

Jovanovic argues that wrong abstraction is more expensive than visible duplication. Copy-paste is local and honest: if the copies drift, that may reveal that they were never the same knowledge. A premature abstraction is global and hidden: callers bend themselves around one shared shape, and the system loses independent evolution.^{source: milan-jovanovic-dry-misunderstood-2026.md}

The boundary problem is strongest across modules or bounded contexts. A Billing.Order and a Shipping.Order may share fields while representing different views of the real-world order. Merging them into a shared type to avoid repeated properties can weld independent modules together, undermining modular monoliths, vertical slices, and context-local ownership.^{source: milan-jovanovic-dry-misunderstood-2026.md}

A practical heuristic from the article is: wait for the third occurrence, then ask whether a rule change would require all copies to change together. If yes, the copies encode the same knowledge and should be extracted. If no, their similarity is incidental and duplication is safer. A second tell is naming: Money, TaxRate, or InvoiceNumber suggests a real domain concept; Helper, Utils, or ProcessData suggests shape-based abstraction.^{source: milan-jovanovic-dry-misunderstood-2026.md}

This is relevant to ai-assisted-software-development because coding agents can generate, deduplicate, and refactor quickly, but they can also amplify premature abstractions when review focuses on surface similarity instead of domain meaning. It also complements modern-engineering-values: agent-era engineering still needs taste, boundary judgment, and the willingness to keep code boring until a true concept emerges.

Resources

DRY Is the Most Misunderstood Rule in Programming