100% Free Forever
AI-Powered Learning
Industry Expert Content
Certificates & Badges
Learn At Your Own Pace
Programming

DRY Principle

IntermediateConcept11.8K learners

DRY ("Don't Repeat Yourself") is a software development principle stating that every piece of knowledge or logic should have a single, unambiguous representation within a system, rather than being duplicated across multiple places.

Definition

DRY ("Don't Repeat Yourself") is a software development principle stating that every piece of knowledge or logic should have a single, unambiguous representation within a system, rather than being duplicated across multiple places.

Overview

The DRY principle was articulated by Andy Hunt and Dave Thomas in their 1999 book The Pragmatic Programmer. Its central claim is that duplication of logic — not just duplicated code, but duplicated business rules, data schemas, or configuration — creates maintenance risk: when a rule changes, every duplicated copy must be found and updated correctly, and missing one introduces bugs. Applying DRY typically means extracting repeated logic into a shared function, class, module, or configuration source, so that a change is made in exactly one place. This is a major motivation behind refactoring, and it underlies common object-oriented patterns described in Design Patterns as well as the broader idea of Clean Code. DRY is easy to over-apply, however. Two pieces of code that look similar today but represent conceptually different rules can diverge over time; forcing them into one shared abstraction prematurely can create awkward coupling. This tension is why many teams pair DRY with YAGNI and KISS — duplication should be removed when it reflects true shared knowledge, not merely superficial similarity. In practice, DRY is one of the most frequently cited principles in code review and is a staple topic in software engineering interviews and onboarding material.

Key Concepts

  • Coined by Andy Hunt and Dave Thomas in The Pragmatic Programmer (1999)
  • Targets duplication of knowledge and logic, not just duplicated text
  • Encourages extracting shared behavior into functions, modules, or config
  • Reduces the risk of inconsistent bug fixes across duplicated code
  • Frequently paired with KISS and YAGNI as core pragmatic principles
  • Can be over-applied, creating premature or awkward abstractions
  • Widely taught in software engineering courses and interviews

Use Cases

Extracting a repeated validation rule into a single shared function
Centralizing configuration values instead of hardcoding them in multiple files
Consolidating duplicated database queries into one reusable method
Guiding decisions during refactoring sessions and code review
Designing shared UI components instead of copy-pasted markup
Building single sources of truth for business rules across services

Frequently Asked Questions