Don't DRY Your Code Prematurely

It's important to remember that all best practices are not created equal. I'd prioritize readability over DRY. I'd prioritize cohesion over extensibility. When people talk about best practices, they don't talk about how a lot of them are incompatible, or at least at odds with each other. Writing code is about choosing the best practices you want to prioritize as much as it's about avoiding bad practices.

Sometimes it's best to be DRY right from the start.

Several years ago, I did some contract work for a company that needed importers for airspace data and various other kinds of data relevant to flying.

In the US, the Federal Aviation Administration (FAA) publishes datasets for several kinds of airspace data. Two of them are called "Class Airspace" and "Special Use Airspace".

The guy who wrote the original importers for these treated them as completely separate and unrelated data. He used an internal generic tool to convert the FAA data for each kind of airspace into a format used within the company, and then wrote separate C++ code, thousands of lines of code each.

Thing is, the data for these two kinds of airspace is mostly identical. You could process it all with one common codebase, with separate code for only the 10% of the data that is different between the two formats.

When I asked him about this, he said, "I have this philosophy that says if you only have two similar things, it's best to write separate code for each. Once you get to a third, then you can think about refactoring and making some common code."

That is a good philosophy! I have often followed it myself.

But in this case, it was obvious that the two data formats were mostly the same, and there was never going to be a third kind of almost-identical airspace, only the two. So we had twice the code we needed.

One of the #1 issues I’ve seen with DRY over the years seems to stem from a misunderstanding of what it means.

DRY is not just about code duplication, it’s about information/knowledge duplication, and code happens to be one representation of information.

Hyper focusing on code duplication quickly gets into premature optimization territory, and can result in DRYing things that don’t make sense. Focusing on information duplication leaves some leeway for the code and helps identify which parts of the code actually need DRY.

The difference is important, and later editions of the Pragmatic Programmer call this out specifically. But the concept of DRY often gets a bit twisted in my experience.

Not a conclusive example.

In the industry code that isn't DRY is a much bigger problem than code that is too DRY.

Generality can really hurt performance. Duplicating specialized code to handle different cases can really help optimize specific code hot spots for certain data patterns or use cases.

So DRY isn’t an obvious default for me.

The example is hilariously terrible. Firstly, this is the currently required code:

    def set_deadline(deadline):
      if deadline <= datetime.now():
        raise ValueError("Date must be in the future")
    
    set_deadline(datetime(2024, 3, 12))
    set_deadline(datetime(2024, 3, 18))

Now, as far as teaching best practices goes, I also dislike this post because it doesn't explicitly explain the pros and cons of refactoring vs not refactoring in any detail. There is no guidance whatsoever (ie: Martin Fowler's Rule of Three). This is Google we're talking about, and newer developers could easily be led astray by nonsense like this. Addressing the two extremes, and getting into how solving this problem requires some nuance and practical experience is much more productive.

DRY code (usually with lot of IF blocks to handle special cases, or various oop lasagna) eventually turns into unmaintainable nightmare where every trivial new feature can take hours to implement and is very difficult, full of cussing, hair-pulling kind of programming where every 5 minutes you think "we need to rewrite everything from scratch, the system wasn't designed for this". Every change breaks million different unrelated things because of the complexity of extremely dry functions.

In WET code (write everything twice) everything looks primitive, as if it was written by complete newbie, and every change needs to be added at multiple places, but each change is trivial and time to finish is predictable. I would go as far as calling the code boring. The most difficult thing is to resist the temptation to remove the duplicity.

DRY is _not a best practice_. Repetition is a "code smell" - it often suggests a missing abstraction that would allow for code reuse (what sort of abstraction depends on the language and context), but "blindly-drying" is in my experience the _single most frequent mistake_ made my mid-to-senior engineers.

My experience is mostly in Ruby though, so I'm not sure how well it generalizes here :-)

Your code should be WET before it’s DRY (Write Everything Twice).

I don't know about anyone else, but I've been deeply unimpressed with the output of the google testing blog.

This example is not wrong, but it's not particularly insightful either. Sandi Metz said it better here, 8 years ago https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction

The testing pyramid nonsense is probably the worst one though. Instead of trying to find a sensible way to match the test type to the code, they pulled some "one size fits all" shit while advertising that they aren't that bothered about fixing their flaky tests.

The article builds a straw man though. The "bad example" is bad because it introduces OOP for no reason at all.

What's wrong with:

    def set_deadline(deadline):
      if deadline <= datetime.now():
          raise ValueError("Date must be in the future")

    set_task_deadline = set_deadline
    set_payment_deadline = set_deadline

I mean, sure. I'm generally more WET than most of my colleagues, but this...

Applying DRY principles too rigidly leads to premature abstractions that make future changes more complex than necessary.

... is just one of those things that sounds wise, but is just basically a tautology. Use the best tool for the job, etc. No kidding? Would never have thought of that on my own, thanks sensei.

Seriously, the issue with the quoted statement is not that it's new to anyone, it's that no one thinks they ARE applying DRY principles "too rigidly". This is just chin beard stroking advice for "everyone else".

Reminds me of a conversation I had with a project manager. To match the example, I'll recast it in terms of deadlines.

Project manager: Sam is working on a deadline validator. You made a deadline validator last sprint right? Could Sam use yours?

Me: No, unfortunately not. My deadline validator enforces that deadlines are in the future and are aligned with midnight UTC, to ensure correct date calculations in the database. The deadline validator Sam is working on does not enforce those restrictions. Sam's deadline validator will be applied to user input for an entirely different field, where deadlines don't have to be at midnight and are just as often in the past as in the future. In fact, Sam's validator only checks that a deadline string has the expected format and is within twenty years of the present day. My validator operates on timestamps sent as integers from another service, not string values uploaded by users.

Project manager: So your deadline validator is not reusable at all? That's unfortunate. Is there something we could have done differently to avoid this redundant work?

People talk about DRY and then happily type pip/gem/npm into their terminal, and never look at 99 percent of what they just downloaded...

Did we all forget leftpad? https://qz.com/646467/how-one-programmer-broke-the-internet-...

My rule: repeat yourself 3 times. On the 4th, re-factor.

I think the only hard and fast rule is to DRY the code that will introduce a bug if you change it in one place and not the other. And if it will, at least do a fat comment in both places for posterity.

Whenever I have to have a "mental model" of the code, I know I screwed up.

A practical rule for the presented problem is "wait until you have 3". The number being in reference to the amount of different cases which need to be handled. You're not likely to catch everything that will come up but you'll get enough to think of an extensible abstraction if you don't realize that you already have a workable one.

The term "DRY" as commonly used conflates distinct situations and objectives that should be handled differently in most cases.

There is the "single source of truth" problem where you need to compute something exactly the same way at all points in the software that need to compute that thing. In these cases you really want a single library implementation so that the meaning of that computation does not accidentally diverge over time since there is a single implementation to maintain.

There is the "reuse behaviors in unrelated contexts" problem where you want to create implementations of common useful behaviors that can be abstracted over many use cases, often in the context of data structures and algorithms. In these cases you really want generics and metaprogramming to codegen a context-specific implementation rather than sharing a single implementation with a spaghetti mess of conditionals.

DRY works best when it fits neatly and exclusively into one of these two categories. Cases that fit in neither category, such as the practice of decomposing every non-trivial function into a bunch of micro-functions that call each other, are virtually always a maintenance nightmare for no obvious benefit. Cases that fit into both categories, such as expansive metaprogramming libraries, become difficult to maintain by virtue of the combinatorial explosion of possible implementations that might be generated across the allowable parameter space -- the cognitive overhead grows exponentially for what is often a linear increase in value.

https://grugbrain.dev/#grug-on-dry

grug begin feel repeat/copy paste code with small variation is better than many callback/closures passed arguments or elaborate object model: too hard complex for too little benefit at times

hard balance here, repeat code always still make grug stare and say "mmm" often, but experience show repeat code sometimes often better than complex DRY solution

something i have learned the hard way is that DRYing out too fast paints you into architectural corners you don't even know are there yet.

I think DRY should be more "Don't repeat assumptions".

Or rather, don't assume the same thing in two different places, especially not implicitly.

Avoiding code duplication mostly follows from that.

This DRY principle has ruined so many code bases merging so many facets into one giant monster of complexity that then later has to be specialised with flags and enums that I can't count how many times I have seen such clever PRs.

IMHO - some of the clean code books have ruined the industry as much as the virtues of microservice preachers have.

The second number goes to the Javascript tooling.

This reads like a paraphrase of this widely circulated post from 8 years ago…

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

Reminds me of this[1] great blogpost: "This abstraction adds overhead. “Abstracting” the common operation has made it more difficult to read, not less difficult to read. People for who consider meta-programming some sort of Black Magic often make this exact point: The mechanism for removing duplication adds complexity itself. One view is that the overall effect is only a win if the complexity added is small compared to the duplication removed."

[1]: http://weblog.raganwald.com/2007/12/golf-is-good-program-spo...

To the author: please do not use non-ascii quotes (“”) in code.

The problem with all the "best practices" is that quite often they are sensible within some context but can be a detrimental tradeoff in a different one.

"it depends" is almost always the correct answer.

But what we see is young, inexperienced and zealous coders trying too hard and implemented the so called best practices before they understand them.

And I don't think there are too many shortcuts to replace experience.

My advice for beginners and intermediate is to first stick to the simplest solution that works, and don't be afraid to rewrite.

In an unrelated note, this "Google Blog" thing appears to have [at least] three different domain names that redirect to the same url: https://blog.google.com, https://blog.google and https://googleblog.com, why is that?!

Fixing duplication is far easier than the wrong abstraction.

Don't use DRY but WET: Write Everything Twice. :o)

In practice: The second time you implement something, start out by copy-pasting the first implementation. Once you're done with the second version, figure out if and how to abstract the two implementations.

I think it depends on how you deduplicate your code. Creating a DeadlineSettter as illustrated is definitely too much, but creating a function:

  def assert_datetime_in_future(datetime):
    if datetime <= datetime.now():
      raise ValueError(
        “Date must be in the future”)

I find the term DRY to be pretty vague.

Let’s say you have a business rule that you can never have more than 5 widgets. You can make this assumption in multiple places, even with totally different code, and that’s damaging DRY when the rule changes to allowing 6. On the other hand, having a bit of duplicated HTML can help, as they may only be the same by accident.

DRY is more about support and maintenance than anything else.

I see a lot of attacks on DRY these days, and it boggles my mind. Maybe it is being conflated with over-engineering/paramterization/architecting. I don't know.

But I do know that having to fix the same bug twice in the same code base is not a good look.

Boilerplate that you can't get wrong is better than DRY in most cases

by "get wrong" I mean through static analysis (linters or type checkers) or if it is plainly obvious by running it.

There is an unpraised advantage of keeping code, uh wet?, for as long as possible. When you do decide that a refactor is required, you have real use cases to test your abstraction against. While I am broadly in agreement with the article because of that, people designing public binary APIs don't have the luxury of delaying these choices.

Seems like a strawman. The thing being repeated here is something which raises if the datetime isn't in the future. So abstract that out and you then get both methods calling raiseIfDateTimeNotInFuture() which then also serves as documentation.

(But yes, if the actual code is as simple as this example, you may as well just repeat it.)

Especially with AI. It’s better to teach the AI many examples and let it understand the implicit abstractions. Who needs to worry about reusable higher order abstractions when the machine just busts out the code you need in a single file?

Related: I do believe starting off at the "second" level of abstraction (as opposed to implementing the direct surface area of the service) is not premature as it helps to better understand the problem space, and on the implementation side, as soon as you identify the building blocks, the rest would be really just boilerplate. if you got time, rinse and repeat.

This comes from within Google, which strongly embraces Go -- a language famously impaired when it comes to abstraction capabilities. This opinion has been voiced here before: https://news.ycombinator.com/item?id=8316520

Domain knowledge is just as important when programming as the craft itself, this is why I have to have a great relationship with subject matter expert and develop domain knowledge fast. So abstractions can be a better fit

I wonder why nobody mentioned it - there is one more advanced principle AHA: (Avoid Hasty Abstractions) https://kentcdodds.com/blog/aha-programming#aha- Overusing the DRY principle can make software almost unsupportable.

This is a poorly-selected example, as the real problem here is not the DRY validation, it's that the programmer is abstracting the wrong thing.

Ending up with an awkward class name like `DeadlineSetter` is a dead giveaway that your abstraction boundaries don't make sense - if instead you abstract `Deadline`, and put the invariant check in the constructor thereof, you solve both problems.

It sometimes takes time to discover the best approach to writing code that handles similar inputs. I once worked on an ingestion pipeline that was supposed to clean up data sent to us by a person whose sole job was to sit in front of a Windows PC running three pieces of software:

a) a terminal running a text mode app extracting data from a mainframe

b) Excel

c) Outlook

Their sole job was to copy data from the terminal, paste it into Excel on a daily basis, save it as a CSV file, and send it as an attachment to the address monitored by a script that was responsible to running data processing pipeline. Because of the manual nature of the job and the way data was presented in the terminal there were errors, which were really unpredictable. I was not allowed to talk to the person doing this job or visit them in their office so it took me three months to find out that what was shown on the terminal screen was essentially a 80x25 version of a punchcard and that position of the fields mattered. Sometimes the user would not copy the whole screen, sometimes there would be an extra character added while pasting data into Excel (not always a stray "v"), sometimes a gremlin character would be added between the mainframe and the terminal (there must have been a serial connection somewhere). Forget proper encoding, JSON or XML, it was raw data, really raw. When I started working on the pipeline it would break on every incorrectly formatted record, when I finished the job and left it was only barfing on 5% bad records and those that it could not process would be neatly put aside an emailed to the support people responsible for dealing with this client. There was a lot of repetition initially, but I then discovered patterns (random offsets, encoding errors, extra characters) and that allowed me to build a set of generic classes to quickly implement problem-specific handlers.

People focus too much on DRY and not enough on modularisation.

If your functions do everything, DRYing them can be awkward and ineffective. If you stop injecting your business logic into every line and attempt to create "pure" functions, it's so much easier to sprinkle the occasional `if(input.type2) pow(input, 2)` in the business part.

If your codebase isn't at least 20% "utils", I don't want to touch it. I regularly dip into code I wrote months/years back and reuse it without much thought.

“Anytime you apply a rule too universally, it turns into an anti-pattern“.

Quote from Will Larson found in another HN post (https://review.firstround.com/unexpected-anti-patterns-for-e...) right after checking out this one.

Jimmy Koppel wrote about this 6 years ago [1]. It's one of the first exercises in his software design course [2].

Two identical pieces of code can have different specifications.

  # x is an age of a person; the code checks if the person is past the retirement age in the US
  def is_of_retirement_age(x):
    return x >= 65;

  # x is an ASCII character which is already known to be alphanumeric; this code checks if it’s a letter.
  def is_ascii_letter(x):
    return x >= 65;

[2] https://www.mirdin.com

My rules on code duplication:

- For code in different files you get 3

- For code in the same file you get half a dozen

- For code in the same function you get more like a dozen

- For code in a single repeated block you get as many as you want

It is especially hurtful when people apply DRY immediately on some spaghetti code already mixing abstractions.

Then you find yourself untangling intertwined fatorized code on top of leaky abstractions, losing hours/days and pulling your hair out… (I’m bald already but I’m pretty sure I’m still losing hair in these situations)

This is especially true for a data scientist, where most code is throwaway. If you make it all spectacular, you aren't getting anything done. Data scientists' code should be "eventually good," that is to say it gets refactored as it approaches a production environment. I talk about this in my last book, Agile Data Science 2.0 (Amazon 4.1 stars 7 years after publishing).

https://www.amazon.com/Agile-Data-Science-2-0-Applications/d...

I will say that after 20 years of working as a software engineer, data engineer, data scientist and ML engineer, I can write pretty clean Python all the time but this isn't common.

Sedat wrote about this and other useful stuff.

https://www.manning.com/books/street-coder

So refreshing to see this kind of wisdom in a concise blog post!

My take:

In beginners, over-emphasis on DRY is a mistake made because they don't yet understand why DRY is considered a best practice.

In more senior developers, over-emphasis on DRY comes from a few psychological desires... 1) to mitigate the uneasy feeling of not knowing what direction the product will take, and 2) the warm feeling that comes from finding a refactor that makes the code more DRY.

What is overlooked is the cognitive overhead required to un-DRY pieces of code when requirements change. Often the result is a DRY but convoluted series of refactors that obscure the intention of the code and (often) obscure system design intention that would otherwise have been quite clear.

Sadly, many otherwise talented software engineers have the kind of minds that prefer micro-level problem solving and are challenged at big-picture reasoning. There is often actual discomfort when too much big-picture reasoning or synthesis is involved. I view this as more of an emotional than a cognitive limitation, and something that is amplified by the conformist culture found in most large organizations (and which many small ones believe it is best to emulate).

Conformity with best practices is valued above real problem solving. Worse still, there are often elaborate discussions of PRs relating to minutia associated with DRYing up code for which it wasn't necessary in the first place.

Sure, as a system matures there are opportunities to remove cruft and DRY code where it is obviously helpful, but it is silly to waste too much time on it until the true requirements of the system are well understood.

Is the duplication truly redundant or will the functionality need to evolve independently over time?

"Looks the same right now" != "Is the same all the time"

Bad abstraction is worse than no abstraction

I still practice DRY, but I try to not overdo it with unnecessary abstractions. More recently I've been practicing SPOT (Single Point of Truth). I interpret this in two ways. One, every piece of data should have a location that reigns over all others. It's okay to have duplicates of the data, such as caches, but any copies of that data should be treated as ephemeral and possibly inconsistent with the source of truth. Second, there is some overlap with DRY where some logic that answers a question or computes a result should not be duplicates. A specific function or class which computes something important, should probably not be duplicates, but implemented once and reused. A great example is authentication, you most likely should not duplicate code that checks whether a user is authorized to do something. In a sense, the code which computes whether a user is authorized in itself becomes a "source of truth".

There are still good reasons to DRY early on. Actions that need to be performed synchronously, rather than acquiring the same lock in several places, consolidate your code so you're so there's at most a few places you acquire and release that lock. Cache invalidation, having a single class for reading and writing some piece of data makes it much easier to keep the cache consistent.

Anecdotal but I've found it much easier to start DRY and then later duplicate code that diverges a little bit from the original. What is hard is working with a large code base with lots of duplicate code. When you need to change one thing, but there's multiple places you need to make that one change, I've found it very difficult to track down all the places which need to be changed.

When you can't DRY, or when it's simply not practical, at least try to find a way of keeping track of duplicate code. Using enums and global constants can help you by finding all the references to those symbols and locate all the places in your code which need to be updated or refactored.

I tend to follow "1, 2, many"

Duplication in one place, I'm often fine with, because you don't yet know the level of abstraction needed with only two examples.

More than twice however and you should be able to see common patterns across all three implementations and be able to isolate it.

This DRY-sceptical viewpoint is a bit similar to database denormalization.

Sure, in theory you want to store every bit of information only once. But in practice it can make a real difference in smoothing out the access pattern if you don’t follow this normalization religiously.

The same applies to code. If you have to jump through hoops to avoid repeating yourself, it will also make it harder for someone else reading the code to understand what’s going on. A bit of “code denormalization” can help the reader get to the point more quickly.

I know it's supposed to be catchy but "Don't Repeat Yourself" is quite too dogmatic. A little redundancy can absolutely help readablity. Obviously you don't want to repeat complicated code blocks that you have to maintain twice.

What this industry has taught me:

1. DRY initially when your organization is afraid of refactoring because they'll never let you touch it a second time if "it works".

2. DRY later when it's clear the code will not change into genuinely separate branching workflows.

3. DRY it initially when mid-level management uses duplication as a metric to evaluate "good" engineers, especially when your salary is impacted by that perception.

1 and 3 have been a symptom of micro-management from the business side. Only 2 is valid.

When I asked him about this, he said, "I have this philosophy that says if you only have two similar things, it's best to write separate code for each. Once you get to a third, then you can think about refactoring and making some common code."

There is also the angle of when eventually the third usecase comes out, how much willingness/buy-in is going to be there to make changes to the running code for the refactoring?

Quite often than not, nobody wants to take the risk for the sake of introducing DRYness and you end up with three copies.

I don't think the distinction between DRY or don't DRY is interesting at all. Instead what matters is how the abstraction is achieved/performed. Good abstractions stand the test of time, poor ones leak.

The main benefit of abstraction isn't to reduce keystrokes; it's to break a program into comprehensible chunks of operation.

Routines that are conceptually identical should share an abstraction. A concept might benefit from an abstraction even if it is only used once. It is never too early to add more intuitive abstractions to your code.

On the other hand, code that is only coincidentally similar in execution should never be forced to share an abstraction.

Cool tip! I learned that reading other people's code and seeing how much they could get done with far fewer lines of code and much faster than I cause they didn't over-engineer from the start. I got the bad habit of making a big architecture from the beginning because I read many books from academics talking about beauty and elegance, while I admired people in the industry the could get cool things done.

Now I have the experience that most of my projects I only understand after months (or years!) of development, observing the users and testing. Only after I have experience in the project I can actually know what should be the focus of my engineering.

The example is terrible. It's understandable that OP wants to keep it as short as possible. But it is made so simple that it fails to convey the point. You would obviously not want to use the DeadlineSetter class here. It doesn't even ever access its "entity_type" field.

All code bases I have seen in the past 15 years have too little DRY, not too much. Yes, every technique we use has pros and cons and we need to decide in each case whether DRY is worth it. But I worry that people will come away from the article (or even just the headline) with the feeling that "ah, I don't need to DRY". I've been in the situation too many times where somebody copy-pasted and I later had to make it DRY to achieve consistent behavior. Let's err on the side of DRY.

In the example, the right-hand side could either be left as-is. Or it could extract a function:

  def set_task_deadline(task_deadline):
    _ensure_is_in_future(task_deadline)
  
  def set_payment_deadline(payment_deadline):
    _ensure_is_in_future(payment_deadline)
  
  def _ensure_is_in_future(deadline):
    if deadline <= datetime.now():
      raise ValueError(“Date must be in the future”)

Just grug it out

also never write tests for code that doesn't exist because you gradually slow down learning to a crawl and you are no longer writing features but tests and mockups that offer nothing to the end user.

My maxim: is "it" intrinsically the same, or coincidentally the same?

Intrinsically the same means a rule, and so there should be 1 source of truth for it. Coincidentally the same means it has the same shape but this just happens to be the case, and they should be left separate to evolve independently.

Ultimately, it boils down to really thinking about the domain.

In my experience DRY and many (any?) other coding principles are only problematic when misused. They're typically misused because the user doesn't understand the motivation or underlying value of the principle in the first place.

I think the example in the article does a bit of that as well. The example sets a deadline on a thing (a task or payment) by validating the deadline against the current time, and then presumably doing something else that isn't shown. The article argues that in the future a task might have different validation requirements than a payment, and they're only coincidentally the same today; so it would be foolish to abstract the deadline setting logic today. BUT, the reality is that the real coincidence is that payments and tasks have the same set of validations, not that the logic to validate a deadline is coincidentally the same. In my opinion "good" code would be fine to have separate set_task_deadline and set_payment_deadline methods, but only one validate_deadline_is_in_future (or whatever) method, alongside other validation methods which can be called as appropriate by each set_x_deadline implementation.

Disclaimer: the code is so short and trivial that it doesn't matter, I think we can all assume that this concept is extrapolated onto a bigger problem.

Reading a lot of this discussion I'm thinking whether DRY itself is the problem or it's more about mixing different (but perhaps comparable) things into one function (be it for the sake of appearing DRY or otherwise).

Rules of thumb are meant to be broken, they aren't laws.

The visualizations in Dan Abramov’s talk “The wet codebase” [1] really burned this concept in for me.

Seeing what a premature, wrong abstraction looks like visually was eye opening.

[1] https://youtu.be/17KCHwOwgms

My rule of thumb is the third time I rewrite some code, I DRY it.

Like any rule this can be taken too far. It happens all the time. People like simple rules. They want everything to be like assembling IKEA furniture: no thought required, just follow the instructions. We all like it because it frees up the mind to think about other things.

There are rules like "don't stick your fingers in the plug socket". But, if you're an electrician, you can stick your fingers in the plug socket because you've isolated that circuit. DRY is similar. As a programmer, you can repeat yourself, but you should be aware that it's thoroughly unwise unless you know you have other protections in place, because you know why such a rule exists.

I suck in the kitchen. If you asked me to make you a sandwich, I would have to go to the cupboard or refrigerator a few times to end up with all the right ingredients. Then I could at least competently assemble the sandwich. My family also loves antipasto salads, which are basically just like a sandwich without bread.

If you asked me to assemble 10 different sandwiches, and 1 antipasto salad, some of which I'm seeing for the firs time, I would attempt to gather all the ingredients, but ultimately end up going back and forth between the cupboard and refrigerator still. I might even think, on one of those trips, hey, I don't need the mayo anymore, so I can put it away, only to have to go back and get it again for a later sandwich. The end result would probably be all the ingredients for every sandwich on the counter at the same time, as I should have done.

I'm pretty smart though. I'm good at Abstraction. So, I assume I'm going to get another order from the family for a sizable amount of sandwiches and some more antipasto salad. I name each sandwich and salad type and then write down a list of ingredients for each sandwich so I can cross-reference it to assemble a master list of all required ingredients per sandwich when the next order comes in. I can then go to the cupboard and refrigerator once.

I then order each sandwich type by their shared ingredients, so that I can apply ingredients only once until I'm done with that ingredient (and then I could put it away, but I'm not a premature optimizer). The only issue is that some ingredients require slicing, like tomatoes, and tomatoes aren't sliced in the same manner for the salad as the sandwiches, and my daughter can't stand when the tomatoes and lettuce touch on her sandwich, and my other daughter wants the cheese and the meat separate. I don't want to overcomplicate the problem, but I don't want to Repeat Myself either, since I know I can grab the tomatoes and slice them all up in the same step, so I need to remember when I assemble my list of ingredients per sandwich and salad that some are exempt from the ordered application of ingredients and must be handled by a single, separate script for assembly.

I run this process a few times, and it works, but I learn that it takes me 35 minutes to do, and that there's now a hard requirement on a frozen item involved with one of the sandwiches that it not be out for more than 10 minutes, so now this ingredient itself must be exempted from the step where I grab all ingredients and my assembly instructions for the one sandwich that involves this ingredient must be very clear that I will still also need to grab that ingredient.

Then I learn/realize:

In-fact, 90% of the time I make a sandwich, or salad, I only make one at a time.

OR

Nobody wants to order sandwiches by name, they just want to give me a list of ingredients in the right order

OR

I am gradually making so many more sandwiches every day that my kitchen counterspace cannot support getting all the ingredients at once

OR

I only make the same sandwiches + one salad every day to the exact same specification

There can be lots of other factors that make a particular refactor more or less desirable. Is the code actually that long or not really, is it already complex or straightforward, was it written well in the first place, etc. Without seeing the particular code, people can jump to any conclusion or justify any bias towards or against any particular refactor including attempts at DRY.

My experience has been that the worst code was also the most poorly tested, if at all. In many cases, you can't really test the code without refactoring it, but you can't refactor it without risking regressions due to lack of tests.

Breaking this cycle requires going back to requirements, whether explicit or by painstakingly inferring every valid use case supported by the intentions of the original code, even if its defects meant it couldn't actually serve those use cases anyway and so cannot even act as a reference implementation for those use cases.

Once you've understood the intended behavior of the old code enough, you now have a test suite to use for any future code. This is usually the hard part [1], and it's going to seem that way because once you have it, finding the simplest code that passes all tests is just programming. Importantly, even if a future maintainer disagrees with you on the best solution, at least they can rewrite it without worrying about regressions against any tested case.

Aside: Performance regressions are more difficult to detect but preparing standard test workloads is a necessary part of that too.

After you ship this rewritten solution you're going to get user issue reports that you broke some edge case nobody has ever explicitly considered before but someone had somehow come to rely on. Now you're only adding a test and logic for that one edge case, you know that no other case was broken by this change, and that this case will never be broken again.

Now you have leverage over the complexity of the project instead of giving it leverage over you. Now you're free to refactor any which way you prefer, and can accurately judge the resulting code entirely on its own merits. You know you're comparing two correct solutions to the same problem, neither one is subtly hiding bugs or missing edge cases. Your code reviewers will also find it much easier to review the code because they can trust that it works and focus the review on its other merits.

[1] You know if your problem domain is an exception better than I do, like if you work on LLVM.

I’ve always found that duplicating and editing over-DRY code is easier than fixing code that’s under-DRY. I strongly prefer working with people that care about DRY code and accidentally go too far than the reverse. Additionally, the worst problems I’ve had in inherited code have been due to duplication and insufficient abstractions leading to logical inconsistency.

This is one of my favorite principles, don't try to make the codebase "too DRY" . I often see it cause stress and complexity in platform or infra teams trying to support large communities of developers.

It's right to be concerned that a bunch of teams might be a wasting time implementing the same thing slightly differently, or that you'll end up fixing the same bug across all these "copies".

Often that kind of duplication is good for the business though, and the platform team doesn't have the insight to see all the divergent requirements on the horizon. Letting the teams innovate separately without having to coordinate changes in all these DRY-ied up systems can be the best way to support them.

Or even more abstractly, zero codebase chaos is not the optimal amount.

But don’t stop telling new developers to be DRY, it’s really just a way to remind them they’re allowed to make functions.

Just step in when they go too far

This is what I found hard about Haskell. It's so tempting to DRY to such a phenomenal degree, but then the slightest requirement change somewhere in the middle breaks some abstraction and bubbles all the way out. It's almost like how a zip encoding of two files that differ by one byte could be completely different.

While the examples may be quite facetious, they often are for demonstrative purposes...

I myself have been burnt by Over-DRYed code - Over-DRYed code tends to lead to God Functions, where 1 change has many unintended consequences. Unintended side effects should be considered a worse scenario over "tedious chore".

In any case, (at least in a API context) a robust test suite focused on end user requirements SHOULD make the mythical "code quality" metric irrelevant.

Just don't prematurely anything and write code that works. If you know how it works you automatically get an intuition what can be made better and where bottlenecks might be. Then you refactor it or just do a plain rewrite.

It's really that simple. (There are always exceptions obviously)

I thought it was Don’t Repeat Yourself more than three times.

Back in my ruby on rails days, we used to have a saying: Don't 'dry out' your code. I still find that to be a good saying to bring up when you're trying to find a good balance between repetitive code vs painfully generic code.

I'm not particularly bothered by having to change several places. The situations where I couldn't solve it with things like grep, find, sed have been very rare, and this kind of solution crops up every now and then.

One of the more common examples is generated code, where I prefer to put that on the side and then copy in the files to the appropriate place in the application and then update things like package declarations in bulk. It makes it harder to overwrite manually added comments or code by mistake.

Tools like ast-grep help too, when more sophisticated search-replace is required.

So I agree, at least in less mature systems DRY is a bad idea that causes a lock-in that will bite you at a later time. Often it's much harder to tear apart a DRY abstraction than creating one.

Yeah, premature DRY is a pet peeve of mine. Especially since the "size" of the code necessary to trigger DRY is totally subjective: some people apply DRY when they see similar blocks of code, others are so averse to repetition they start abstracting out native syntax.

Software development is so varied that blanket statements like this never work.

Never.

I prefer: do the thing when doing so reduces the expected cost of (time-discounted) future outcomes by more than the expected utility of the next best thing you can do now.

The problem with DRY occurs when it contravenes this principal - when deduplication is too expensive and/or unlikely to decrease the cost of future mutations enough to be worth it.

The proposed problem isn't a binary - that you should or shouldn't make the assumption yet - but rather that the assumption has a cost based on what you believe is likely to occur in the future and the value produced by making the assumption now needs to outweigh the cost.

Ah, yes, Google testing blog. From the same company shipping products recommending we eat "at least one small rock per day".

Upper management trying to drive software results by metrics is like trying to win a war with metrics unrelated to battle outcomes.

You must produce X number of tanks, your forces must fire Y bullets, you should minimize the number of retreats.

If you try to manage with no understanding of what's happening on the front lines (and upper management generally can't understand the front lines unless they've worked there recently), you're not going to win the war.

You can never make fast and hard rules about when to repeat yourself and when not to, it probably takes a lifetime to know when to do it correctly. I'm pretty certain programmers are not going to be out of work anytime soon.

Do we have (Python) codebase analyzers that detect subtle duplicates (bane of WET) and overly complex functions called from n places (bane of DRY)?

I have a sticker on my laptop of a yin-yang with DRY and YAGNI instead of the dots.

"premature optimization is the root of all evil"

That's an example for the wrong abstraction, not an example for "no DRY".

Checking if a date is in the future does actually make sense, I would not do it like that (that's more of a `raise_if_not_in_future`), but whatever:

    def check_if_in_future(date):
       if date <= datetime.now():
          raise ValueError(
            “Date must be in the future”)       

    def set_task_deadline(task_deadline):
        check_if_in_future(task_deadline) 
      
    def set_payment_deadline(payment_deadline):
        check_if_in_future(payment_deadline)

Can someone also write an article on how not to write code like is in this article?

`DeadlineSetter` should not be a class, and besides that the implementation makes zero sense. The whole thing should probably just be a single if statement.

The example in the article is too short and incomplete to be meaningful. In a real program there would be something that does actual work for "tasks" and "payments" and deals with errors, providing context for technical decisions instead of forcing the choice of minimum complexity (i.e. two plain functions instead of a class) as the only applicable design guideline.

used once? don't worry, don't think about "what about the possibility it's repeated in the future?"

used twice? okay, maybe I will, maybe I won't

used three+? "don't be lazy ya bum"

I like simple rules, and I don't care if someone wants to turn it into a philosophical debate, I probably won't participate :)

I like a lot the "rule of three" when it comes to have to choose when to DRY.

https://en.wikipedia.org/wiki/Rule_of_three_(computer_progra...

I think this is the best way to think about it:

Ask yourself, if some fact or functionality changes, in how many places would the code have to change?

If it's more than 1, you have a design problem. Of course, the solution does not at all have to be about DRYing.

The question then becomes: when do you break out code or not? Unfortunately (or fortunately if the art and craft or programming fascinates you), the answer is not easy. It seems to have to do with avoiding over-fitting or under-fitting the domain and purpose, to do with getting the best fit in a Bayesian Occam's Razor sense. Minimizing unnecessary code but also doing "Dependency Length Minimization" of the parse tree of your program so that it's maximally understandable and the abstractions increase the potential of your program to correctly interpolate into unknown future use cases. I reflect on some of these points here: https://benoitessiambre.com/abstract.html . It's about entropy minimization, calibration of uncertainty. It's about evolving your code so that it tends toward an optimal causal graph of your domain so that your abstractions can more easily answer "what if" questions correctly. These things are all related.

Like the article ends with, DRY goes hand in hand with YAGNI. The point isn't to build a million abstractions; it's to find the places where you have duplication and de-duplicate it, or where you know there'll be duplication and abstract it, or to simply rearchitect/redesign to avoid complexity and duplication. This applies to code, data models, interfaces, etc.

The duplication is typically bad because it leads to inconsistency which leads to bugs. If your code is highly cohesive and loosely coupled, this is less likely [across independent components].

And on this:

When designing abstractions, do not prematurely couple behaviors

Don't ever couple behaviors, unless it's within the same component. Keep your code highly cohesive and loosely coupled. Once it's complete, wall it off from the other components with a loosely-coupled interface. Even if that means repeating yourself. But don't let anyone make the mistake of thinking they both work the same because they have similar-looking interfaces or behaviors, or you will be stuck again in the morass of low cohesion. This is probably one of the 3 biggest problems in software design.

Libraries are a great help here, but libraries must be both backwards compatible, and not tightly coupled. Lack of backwards compatibility is probably the 4th biggest problem...