DRY Principle

​

What is the DRY Principle?

The DRY Principle is a software development philosophy that advocates for eliminating duplication in code, documentation, and other system artifacts. The core idea is deceptively simple: any piece of knowledge—be it a business rule, a calculation, a data structure, or a user interface element—should exist in exactly one place. When the same information appears multiple times, developers must remember to update every instance, creating ongoing maintenance burden and introducing opportunities for errors.

“Duplication is the primary enemy of a well-designed system.” — Andy Hunt and Dave Thomas, The Pragmatic Programmer

The principle gained widespread recognition through “The Pragmatic Programmer” (1999), a influential book that established many best practices for software development. However, the underlying idea predates the book—programmers have long recognized that duplicating logic creates maintenance nightmares. What Hunt and Thomas did was articulate the principle clearly and give it a memorable name. DRY applies to many forms of duplication. Code duplication occurs when the same logic appears in multiple places. Documentation duplication occurs when the same information is explained in multiple documents. Data duplication happens when the same data is stored in multiple locations. Schema duplication arises when database structures mirror each other. The principle asks developers to identify the single authoritative source for each piece of knowledge and build systems that reference this source.

​

DRY Principle in 3 Depths

• Beginner: When copying and pasting code, stop and ask: “Can I extract this into a function or variable that can be reused?” Even small duplications compound over time.
• Practitioner: Apply DRY at multiple levels—functions, classes, modules, and services. Use techniques like inheritance, composition, and configuration management to centralize knowledge.
• Advanced: Recognize that over-aggressive DRY can create inappropriate coupling. Sometimes duplication is preferable to the wrong abstraction. Balance DRY with the YAGNI and KISS principles.

​

Origin

The DRY Principle was formally introduced in “The Pragmatic Programmer: From Journeyman to Master” (1999) by Andy Hunt and Dave Thomas. The book, which became a cornerstone of software development literature, described DRY as a core principle for building maintainable software. Hunt and Thomas argued that duplication leads to systems that are harder to understand, modify, and extend. The principle built on earlier ideas from software engineering. The concept of “single source of truth” in database design predates DRY, as do practices like defining constants in one place and referencing them throughout code. What made DRY influential was its broad application across all forms of knowledge duplication, not just in code but in documentation, processes, and organizational structures. The timing of DRY’s popularization was significant. The late 1990s saw the growth of large-scale software systems, and developers were increasingly facing the maintenance challenges of duplicated codebases. DRY provided a clear heuristic for making design decisions that would pay dividends over the lifetime of a system. Today, DRY remains a foundational principle taught in computer science programs and followed by professional development teams worldwide.

​

Key Points

​

Applications

​

Case Study

The Ruby on Rails framework famously embodies the DRY Principle. Rails introduces the concept of “convention over configuration,” where common patterns are defined once and automatically applied throughout applications. For example, model definitions in Rails automatically generate database access methods—the same logic is not duplicated in multiple places. When Rails developers need to change how models interact with databases, they make the change in one place, and it propagates throughout the application. This approach has made Rails applications notoriously easy to maintain and modify, with developers reporting significantly less duplicated code compared to frameworks that don’t emphasize DRY as heavily.

​

Boundaries and Failure Modes

The DRY Principle, while essential, has important limitations. First, overzealous DRY can create inappropriate abstractions. Forcing unrelated concepts into shared code can create tight coupling, making both the original code and the “refactored” version harder to maintain. Second, premature abstraction is risky. DRY should guide refactoring of proven duplication, not inspire speculative generalization. Creating abstractions for code that might someday be reused often leads to complex, hard-to-understand systems. Third, some duplication is acceptable—or even necessary. Code that appears similar may have different reasons for existing, and forcing them together creates a false unity. Test code often duplicates structure from production code for good reason: tests must be independently maintainable.

​

Common Misconceptions

​

Related Concepts

​

One-Line Takeaway