Don't repeat yourself

"Don't repeat yourself" (DRY) is a principle of software development aimed at reducing repetition of information which is likely to change, replacing it with abstractions that are less likely to change, or using data normalization which avoids redundancy in the first place.

The DRY principle is stated as "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system". The principle has been formulated by Andy Hunt and Dave Thomas in their book The Pragmatic Programmer.{{cite book |last1=Hunt |first1=Andrew |last2=Thomas |first2=David |title=The Pragmatic Programmer : From Journeyman to Master |date=1999 |publisher=Addison-Wesley |location=US |isbn=978-0201616224 |pages=[https://archive.org/details/isbn_9780201616224/page/320 320] |edition=1 |url=https://archive.org/details/isbn_9780201616224/page/320 }} They apply it quite broadly to include database schemas, test plans, the build system, even documentation. {{cite web

|url=http://www.artima.com/intv/dry.html

|title=Orthogonality and the DRY Principle

|date=2003-10-10

|access-date=2006-12-01

|author=Dave Thomas, interviewed by Bill Venners

}} When the DRY principle is applied successfully, a modification of any single element of a system does not require a change in other logically unrelated elements. Additionally, elements that are logically related all change predictably and uniformly, and are thus kept in sync. Besides using methods and subroutines in their code, Thomas and Hunt rely on code generators, automatic build systems, and scripting languages to observe the DRY principle across layers.

Single choice principle

A particular case of DRY is the single choice principle. It was defined by Bertrand Meyer as:

"Whenever a software system must support a set of alternatives, one and only one module in the system should know their exhaustive list."Object Oriented Software Construction, 2nd edition, page 63 It was applied when designing Eiffel.

Alternatives

=WET=

The opposing view to DRY is called WET, a backronym commonly taken to stand for write everything twice{{cite book |last1=Pai |first1=Praseed |last2=Xavier |first2=Shine |title=.NET Design Patterns |date=2017-01-31 |publisher=Packt Publishing Ltd |isbn=978-1-78646-186-5 |url=https://books.google.com/books?id=t08oDwAAQBAJ |language=en}} (alternatively write every time, we enjoy typing or waste everyone's time). WET solutions are common in multi-tiered architectures where a developer may be tasked with, for example, adding a comment field on a form in a web application. The text string "comment" might be repeated in the label, the HTML tag, in a read function name, a private variable, database DDL, queries, and so on. A DRY approach eliminates that redundancy by using frameworks that reduce or eliminate all those editing tasks except the most important ones, leaving the extensibility of adding new knowledge variables in one place.{{cite web

|url=http://www.theserverside.com/news/thread.tss?thread_id=39358#203288

|title=DRY is for losers

|date=2006-03-08

|access-date=2013-08-31

|author=Justin Lee

}}

This conceptualization of "WET" as an alternative to "DRY" programming has been around since at least 2002 in the Java world, though it is not known who coined the term.{{cite web

|url=http://ziggr.com/javaone2002/

|title=JavaOne 2002: Zig's Notes

|date=2002-08-08

|access-date=2024-01-09

|author=Zig Zichterman

}}

=AHA=

Another approach to abstractions is the AHA principle. AHA stands for avoid hasty abstractions, described by [https://kentcdodds.com/blog/aha-programming Kent C. Dodds] as optimizing for change first, and avoiding premature optimization.{{cite web

|url=https://kentcdodds.com/blog/aha-programming

|title=AHA Programming

|date=2019-04-01

|access-date=2021-05-08

|author=Kent C. Dodds

}} and was influenced by Sandi Metz's "prefer duplication over the wrong abstraction".{{cite web

|url=https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction

|title=The Wrong Abstraction

|date=2016-01-20

|access-date=2021-05-08

|author=Sandi Metz

}}

AHA is rooted in the understanding that the deeper the investment engineers have made into abstracting a piece of software, the more they perceive that the cost of that investment can never be recovered (sunk cost fallacy). Thus, engineers tend to continue to iterate on the same abstraction each time the requirement changes. AHA programming assumes that both WET and DRY solutions inevitably create software that is rigid and difficult to maintain. Instead of starting with an abstraction, or abstracting at a specific number of duplications, software can be more flexible and robust if abstraction is done when it is needed, or, when the duplication itself has become the barrier and it is known how the abstraction needs to function.

AHA programming was originally named "moist code" by Dodds, later again by Daniel Bartholomae,{{cite web |last1=Bartholomae |first1=Daniel |title=Moist code - Why code should not be completely DRY |url=https://startup-cto.net/moist-code-why-code-should-not-be-completely-dry/ |website=The Startup CTO |access-date=11 November 2021 |date=21 August 2020}} and originally referred to as DAMP (Don't Abstract Methods Prematurely) by Matt Ryer.{{cite web |last1=Haus |first1=Ev |title=Using DRY, WET & DAMP code |url=https://evhaus.medium.com/using-dry-wet-damp-code-6ab3c8245bb2 |website=Medium |date=24 December 2020 |access-date=11 November 2021}} There was a different programming principle already named DAMP (Descriptive And Meaningful Phrases) and described by Jay Fields,{{cite web |last1=Fields |first1=Jay |title=DRY code, DAMP DSLs |url=http://blog.jayfields.com/2006/05/dry-code-damp-dsls.html |website=Jay Fields' Thoughts |access-date=11 November 2021}} and the community pushed back against the usage of MOIST, due to the cultural aversion to the word moist.{{cite news |last1=Resnick |first1=Brian |title=Why do so many people dislike the word "moist"? This scientist has a theory. |url=https://www.vox.com/2016/4/28/11521048/moist-gross |access-date=11 November 2021 |publisher=Vox Media |date=28 April 2016}} Dodds called for alternatives on Twitter, and suggested DATE as an alternative before settling on Cher Scarlett's suggestion of AHA.{{cite web |last1=Dodds |first1=Kent |title=3 Minutes with Kent: Write the code first, then make the abstraction |url=https://www.briefs.fm/3-minutes-with-kent |website=Briefs |access-date=11 November 2021 |date=27 March 2021}}{{cite web |last1=Dodds |first1=Kent |last2=Bostian |first2=Emma |last3=Nisi |first3=Nick |title=JS Party – Episode #186: Getting hooked on React |url=https://changelog.com/jsparty/186 |website=The Changelog |access-date=11 November 2021 |date=30 July 2021}}

References

External links

Don't Repeat Yourself at WikiWikiWeb
Once and Only Once at WikiWikiWeb
[https://web.archive.org/web/20131204221336/http://programmer.97things.oreilly.com/wiki/index.php/Don't_Repeat_Yourself 97 Things Every Programmer Should Know (O'Reilly)]
[https://www.red-gate.com/simple-talk/blogs/the-myth-of-over-normalization/ The myth of over-normalization] (discussion of academic extremes vs. real-world database scenarios)
{{cite journal |vauthors=Wilson G, Aruliah DA, Brown CT, Chue Hong NP, Davis M, Guy RT, et al. |year=2014 |title=Best Practices for Scientific Computing |journal=PLOS Biol |volume=12 |issue=1 |page=e1001745 |doi=10.1371/journal.pbio.1001745 |pmid=24415924 |pmc=3886731 |quote=Don't Repeat Yourself (or Others)|arxiv=1210.0530 |doi-access=free }}

Category:Software engineering folklore

Category:Computer programming folklore

Category:Programming principles