Hacker News Reader

Comment by haswell | Hacker News Reader

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.

View on HN

This is why some advice from Sandy Metz really stuck with me.

It is not a problem to /have/ the same code 2, 3 or even 4 times in a code base. In fact, sometimes just straight up copy-paste driven development can be a valid development technique. Initially that statement horrified me, but by now I understand that just straight up copy-pasting some existing code can be one of these techniques that require some discipline to not overdo, but it's legit.

And in quite a few cases, these same pieces of code just start developing in different directions and then they aren't the same code anymore.

However, if you have to /change/ the same code in the same way in multiple places, then you have a problem. If you have to fix the same bug in multiple places in similar or same ways, or have to introduce a feature in multiple places in similar way - then you have a problem.

Once that happens, you should try to extract the common thing into a central thing and fix that central thing once.

It feels weird to work like that at first, but I've found that often it results in simpler code and pretty effective abstractions, because it reacts to the actual change a code base experiences.

The challenge is that if you're not careful, you can end up copy-pasting the same bit of code hundreds of time before realizing it has to be changed.

I once worked in a year-old startup of ~5 developers that found it had written the same line of code (not even copy-pasted, it was only one line of code so the devs had just written it out) 110 times. A bug was then discovered in that line of code, and it had to be fixed in 110 places, with no guarantee that we'd even found all of them. This was a very non-obvious instance of DRY, too, because it was only one line of code and the devs believed it was so simple that it couldn't possibly be wrong. But that's why you sometimes need to be aware of what you're writing even on the token level.

That's why we have principles like "3 strikes and then you refactor". 3 times fixing a bug isn't too onerous; even 4-6 is pretty manageable. Once you get to 20+, there starts to be a strong disincentive to fixing the bug, and even if you want to, you aren't sure you got every instance.

Metz says she adds TODOs and comments that it has been duped. It's one of those things that requires thought, and she even says it's an advanced technique. How many times is too many? I'm not sure, but I can safely say over 100 is WAY too many. Probably 10 is too many. Heck, if you find yourself updating the same code in four different places over and over and over, it's time to abstract. The idea is to let the code sit and let the abstraction reveal itself if there isn't already an OBVIOUS one. As mentioned by the parent poster, you're looking out for these copies to diverge. If four or five copied codepaths haven't diverged after some time, there's a good chance that just from working on it every day you will have realized the proper way to abstract it.

You absolutely do have to be careful. But even so, it's arguable that having to update something in 100 different places is better than updating in one place and having it affect 100 different paths where you only want 99 of them (this is some hyperbole, of course).

How do you monitor all code duplications in the code base? Including ones that have been modified slightly ( such as optimizations, name changes, additional statements in between, etc)

Tests. AFAIC, this isn't something that should be long living. If it is only duplicated in a couple of places and remains unchanged for years, that's probably fine too, because ya... no one is touching it. If one place does need to change and tests still pass that should mean that the other one didn't need to change and you've reaped the benefit from not prematurely abstracting. There are a lot of ways it could play out, though. Often the duplication is very local and obvious. I think a lot of people take "duplication is cheaper than the wrong abstraction" WAY more seriously than its intended. It's actionable way of saying "don't abstract early" as the counter that is usually: "But then I'll have duplication and DRY is the law." Like EVERY piece of programming advice, though, it's not universal.

This really makes me think we should be focusing on cost/benefit, risk/reward, pros/cons at all times. If we have a bug in these 5 copies, will it be too hard to fix in all of them? No? What about these 10 copies? If that sounds like its starting to get difficult, maybe now is the time.

> If we have a bug in these 5 copies, will it be too hard to fix in all of them?

Yes, it will be, because copy-pasted code is never the same verbatim. First and foremost, name changes make it almost impossible to identify different copies. Then, there are different tweaks for each copy to make it suitable for the context. I always DRY early, because it's always free to copy-paste later.

I could make the same argument for not using DRY. The DRY-ed code is hard to change, programmers feel honour-bound to keep using it and tweaking it by adding a variety of parameters to more and more cases, and at the end becomes impossible to understand or update, slowing down development.

Now, what probably should've been 3 abstractions is one incredibly convoluted "abstraction" that makes no sense, and its 3x harder than 3 individual abstractions to deduplicate and inline. It further pulls and invites complexity, as its current size is implicit invitation to include additional cases and places.

Furthermore, while without DRY fixing bugs may've been tedious, now with DRY it may be almost impossible due to high risk of breaking a lot of things that depend on that code. (You might be lucky enough to be able to and have written extensive tests with 100% edge case coverage for it - if that's the case then you've postponed the moment of pain somewhat)

Both can be true. It depends on the context whether benefits exceed costs. Decisions should be made based on a specific context and with thinking applied, not generic rules.

5 copies are already extremely difficult.

It's not like they just jump into your eye when you edit some code.

It depends on the context. In some context, they might actually jump out. In some context, even if they don't, it might be fine, because the larger modules containing the code already have excellent tests and are solid and stable

That means you have to think. Most people hate thinking. Seriously.

Oh yeah we've had those as well. I kinda feel two things about these at the same time.

At a practical level, these situations sucked. Someone had to search for the common expression, look at each instance, decide to change it to the central place or not. They spent 2-3 days on that. And then you realize that some people were smart and employed DRY - if they needed that one expression 2-3 times, they'd extracted one sub-expression into a variable and suddenly there was no pattern to find those anymore. Those were 2-4 fun weeks for the whole team.

But at the same time, I think people learned an important concept there: To see if you are writing the same code, or if you're referring to the same concept and need the same source of truth, like the GP comment says. I'm pretty happy with that development. Which is also why my described way is just one tool in the toolbox.

Like, one of our code bases is an orchestration system and it defines the name of oidc-clients used in the infrastructure. These need to be the same across the endpoints for the authentication provider, as well as the endpoints consumed by the clients of the oidc provider - the oauth flows won't work otherwise.

And suddenly it clicked for a bunch of the dudes on the team why we should put the pedestrian act of jamming some strings together to get that client-id into some function. That way, we can refer to the concept or naming pattern and ensure the client will be identical across all necessary endpoints, over hoping that a million different string joins all over the place result in the same string.

In such a case, early or eager DRY is the correct choice, because this needs to be defined once and exactly once.

This happens with SQL a lot where people copy and paste queries all over the place. Especially for reports, there's always the case where some quick and dirty report was thrown together in 20 mins ends up as something managers can't live without.

Making changes quickly get onerous when the query (or slight variation on it) is pasted into multiple places. Nowadays my org has started to use Power BI so there is also multiple dashboards that all need to be updated.

This is why you shouldn't write one line of code, ever again. /s

We've all been there though, at some point in our careers. Possibly multiples of times (try changing thousands of "echo" statements to call a logger because it was initially meant to be a simple script that just kept growing).

It sucks but I've also been on the other side, where it was DRY but 20% of the calls to the function now needed different behavior. Finding all of those usages was just as hard.

> We've all been there though, at some point in our careers. Possibly multiples of times (try changing thousands of "echo" statements to call a logger because it was initially meant to be a simple script that just kept growing).

Been there - now unless it is a very simple / throwaway code, I always start with logging setup from the start. It also helps with print based debugging because you can tune the output.

You're thinking of Sandi Metz: https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction

I think another big part of deciding to use DRY is the complexity of what you're repeating. Copying and pasting lots of business rules means having to make complex edits whenever that logic needs to change. Having simple rules and a small amount of surface area for data reduces the initial need to have DRY code, and it's easier to take the initial risk of using duplicate code.

At least in my experience, it's easier to start with duplicates of simple logic/data, and use DRY for more complex logic/data. The difficult areas are still those where the logic and/or data fall between simple and complex, or are expected to change often, but unknown whether they will change together or diverge quickly.

Conversely, trying too hard to DRY when requirements at call sites start to diverge can lead to an unnecessary complex single implementation of something where there could be two very similar but still straightforward pieces of code.

Couldn't agree more. There's a great decade-old blog post by Mathias Verraes which illustrates this well, I keep coming back to it: https://verraes.net/2014/08/dry-is-about-knowledge/

Indeed - the acronym comes from The Pragmatic Programmer, and the author defined it in this way. Every blog post I've read criticizing/cautioning against DRY were not doing DRY as originally defined.

DRY is almost always a good thing to do. Coupling superficially similar code is definitely not a good thing to do.

> Coupling superficially similar code is definitely not a good thing to do.

I've taken to calling that activity (removing syntactic redundancy that is only coincidental) "Huffman coding".

Yeah, here's the quote from the later editions addressing this:

> Let’s get something out of the way up-front. In the first edition of this book we did a poor job of explaining just what we meant by Don’t Repeat Yourself. Many people took it to refer to code only: they thought that DRY means “don’t copy-and-paste lines of source.” That is part of DRY, but it’s a tiny and fairly trivial part.

> DRY is about the duplication of knowledge, of intent. It’s about expressing the same thing in two different places, possibly in two totally different ways.

> Here’s the acid test: when some single facet of the code has to change, do you find yourself making that change in multiple places, and in multiple different formats? Do you have to change code and documentation, or a database schema and a structure that holds it, or...? If so, your code isn’t DRY.

I feel like I hear de-duplication of information / knowledge often referred to as "Single Source of Truth"

I think the best way to understand DRY is by thinking about the practical problem it solves: you don't want footguns in the codebase where you could change something in one place, but forget to change the same thing in other places (or forget to change the complementary logic/data in other components.)

The goal of DRY as a refactoring, is first-and-foremost to obviate such developer errors.

And therefore — if you want to be conservative about applying this "best practice" — then you could do that by just never thinking "DRY" until a developer does in fact trip over some particular duplication in your codebase and causes a problem.

> you don't want footguns in the codebase where you could change something in one place, but forget to change the same thing in other places

This. Ironically the example on TFA is vulnerable to this issue. Each of the deadline setting methods has a copy of the validation ensuring that the date is in the future. If it's discovered that we need to ensure deadlines are set no later than the project deadline (since that wouldn't generally make sense), it's awfully easy to only update one and miss the others, especially after code has been added and these implementations are no longer visually near each other. I'm not saying that this means the code must be DRY'ed, but it is a risk from the beginning of the project, so one that needs to be weighed during initial implementation.

The Two Generals Problem is mentioned a lot in databases and networking, and you can take some liberties to extend it to human orgs.

> The Two Generals Problem is mentioned a lot in databases and networking, and you can take some liberties to extend it to human orgs.

In fact, the name probably already gives some hint as to what sorts of human orgs this sort of principle would be applicable in.

And, well, the vast majority of orgs require some sort of coordination.

Someone “yes and”-ed a comment of mine awhile ago to teach me DRY SPOT. Don’t repeat yourself - Single Point of Truth.

I.e. what you said. Couple logic that needs to be coupled. Decouple logic that shouldn’t be coupled.

> misunderstanding of what it means

And in response, people will complain that they're being dismissed with "you're doing it wrong!" Because that happens with everything in programmer-land.

The easy response to someone feeling this way is to point them to the origin of DRY: The Pragmatic Programmer.

In the book, the authors explicitly call out that many people took the wrong idea from the original writing. They clarify that DRY is not about code, it's about what they call "knowledge", and that code is just one expression of it.

People can still disagree, but the original intent behind DRY is very well articulated.

How is applying DRY entering premature optimization territory (maybe relative to LOC?)? I argue it is instead: premature abstraction.

Optimization is specialization (which is the opposite of DRY): to enable DRY you likely need to generalize the problem (i.e. abstract) such that you remove duplication.

I've always seen "Premature Optimization" as an umbrella that covers a variety of cross-cutting concerns, ranging from:

- Performance - Code structure / abstraction - Data structure - Team organization / org structure

I'd argue that DRY (and a focus on abstractions more generally) are optimizations of the codebase. Not all optimizations are optimizing the same thing.

Yeah, it's like reminding people that code can change, so it's ok to have known flaws day 1. Something forgotten too often.

One thing that really goes against the usual programming grain is DBMSes. We're taught to always decouple/abstract things, but I'm convinced that it's impossible to abstract away your DBMS in most applications. It's just too big of an interface, and performance considerations leak right through it. It's always one of the selling points of an ORM, "you can switch databases later," and then nobody actually switches.

This is a more insightful comment than the comment at the top, and also more useful than the blog post.

It's a good distinction to make. In the example given, while the code itself looks and does the same - comparing a date to the current date - they represent two different business logic processes, which can change over time.

I mean if there's more instances of this (the DRY "rule" usually says that you deduplicate if there's 3 or more instances) you could refactor it into a utility like "isBeforeNow", but that doesn't add that much value.

Yeah, applies to databases and documentation especially. Databases have the ol' 3NF, you also want to avoid copying data from one source of truth to another in a multi-service environment, and sometimes I intentionally avoid writing docs because I want the code or API spec (with its comments) to be the only documentation.

Reply on news.ycombinator.com