Don’t Repeat Yourself
(Don’t Repeat Yourself. Don’t Repeat Yourself.)
Context:
Duplication (inadvertent or purposeful) can lead to maintenance nightmares, poor factoring, and logical contradictions.
Duplication, and the strong possibility of eventual contradiction, can arise anywhere: in architecture, requirements, code, or documentation. The effects can range from mis-implemented code and developer confusion to complete system failure.
The Mars Climate Orbiter was lost due to a semantic contradiction: part of the system was working in Imperial units, another in Metric. There was a duplication of knowledge (implicit units), and the duplicates were out of step.
One could argue that the most of the difficulty in Y2K remediation is due to the lack of a single date abstraction within any given system; the knowledge of dates and date-handling is widely spread.
The Problem:
But what exactly counts as duplication? Copy-and-paste is generally cited as the chief culprit (see OnceAndOnlyOnce, etc.), but there is more to it than that. Whether in code, architecture, requirements documents, or user documentation, duplication of knowledge - not just text - is the real culprit.
Therefore:
The DRY (Don’t Repeat Yourself) Principle states:
”Every piece of knowledge must have a single,
unambiguous, authoritative representation within a system.”
It’s okay to have mechanical, textual duplication (the equivalent of caching values: a repeatable, automatic derivation of one source file from some meta-level description), as long as the authoritative source is well known.
