There’s always a time when you simply have to break a rule, even if everything you know as a coder says there must be another way.

Good examples of when DRY may not be the best strategy to use right off the mark include:

• Code that, for all you know, is a one-off. I generally have a “three-strikes” rule for refactoring; “make it work, make it clean, make it SOLID”. If I’m writing a line of code to do something, and I have another line of code somewhere else that would do that thing with a tweak here and there, then I hit Ctrl-C, Ctrl-V and don’t give it a second thought. Why? Because I’m not getting paid for pretty code, I get paid for working code. Easy-to-maintain, reusable code is for my benefit, and it’s only a benefit if I expect to go in and make changes. If I don’t, then until I’m proven wrong, ivory-tower development rules just get in the way of a working program (and my paycheck). HOWEVER, once I am proven wrong, by having to go back in that code file and make a change, then I have to be disciplined enough to go back in and clean up, paying off the “technical debt” early instead of compounding it with more spaghetti.

• Testing code. This is a significant subset of the above point. If you are writing a test for a variation on existing behavior, and you have a test exercising pre-existing behavior, then copy the test. Tests are typically “write once, run many”, with very little maintenance needed once the tests go green, so they’re the perfect example of a piece of code you’ll likely never see again. Of course, you still have to be disciplined enough that the first time a change is required to both tests (or the fourth of fifth time you copy the same test to make another), you look for ways to ensure further changes happen in one place, not two (or six or ten or…).

• Implementations of an interface or abstract base class. Even though you might think of these as being the primary way to avoid repeating yourself, the truth is that setting up multiple classes as implementations of some base type involves a lot of very similar-looking boilerplate, not all of which you can avoid. This is especially true if the hierarchy follows a Template Method pattern where a big driving function in a base type depends on specifics in derived types; if you have ten classes implementing this base type, odds are good at least two of them will end up with the same implementation for one of the stubbed methods. Not enough to justify pulling that implementation up into the base, but it’s repeated code. Interfaces, which can’t have any code, suffer from duplicate implementations almost by definition.

There are other examples, but these are a few of the ones I typically encounter. In short, DRY is not a hard and fast rule, it’s just one of those things you keep in mind, and when you do repeat yourself, it’s a “code smell”, indicating you might be incurring technical debt or just generally screwing up. When your code “smells”, it’s worth a second look, but a smell is not always a genuine problem, and even if it is it may not be one worth solving (or even one that is possible to solve).

SQL Server. Scalar user-defined functions in a T-SQL query prevent a parallel execution plan and can also have other negative effects on performance.

Hugo Kornelis explains it nicely here.

…it’s easy to see why using functions to encapsulate and reuse common computations is considered a best practice. But SQL Server isn’t a traditional programming language. It’s a declarative language, with an optimizer that has been designed to optimize the execution order within queries to make sure that the results are returned as fast as possible

DRY exists for a reason, because the more places that the same code exists, the more chances there are of bugs arising from one of those places not being changed when the system needs to change. It is also, obviously enough, easier to test if you only have any given part of your code in one place. Consequently, in most cases where I need to do something more than once I will break it out into it’s own function or method.

One place where I think repetition is alright, or even helpful, is when you have the same code working with different intents – so you might have a function or method that shows very similar behaviour, but in one place it is part of the system for retrieving a user from an authentication system and in another it is retrieving some data from a store. Even if the code is identical this can exist in different places because it is part of different flows and with these divergent intentions it is very likely that they will diverge at some point in functionality. If I was sharing the code at that point, I would have to make things more complex and less readable.

That said, if I have the same or very similar code in multiple places that starts to smell WET to me and I will certainly get to thinking about whether I could be abstracting the relevant behaviour in a way that would facilitate sharing.

When runtime efficiency matters, repeating yourself (e.g. unrolling loops) might be beneficial because some work that should be made at runtime is done earlier. Ideally, such things should be done by a compiler.

Also, when you work with a language that does not offer the kind of genericity that would allow you to avoid repeating yourself, you might need to duplicate things.

Apart from that, stick with the two rules of DRY:

1. Do not repeat yourself
2. See 1.

The problem with lower level languages is not that it “may be a good idea” not to stay DRY when using the specific language. The problem is that it can be hard to impossible to stay DRY if your language lacks certain means of abstraction.

For example, if your language does not provide any kind of higher order functions (or at least pointer-to-functions), try to implement something like a generic, reusable root finder, for example, a generic Newton solver. If your language does neither support generics nor an “common object base class” nor a void *, try to implement something like a reusable list.

For such examples, it maybe the only feasible solution to implement an algorithm or datastructure more than once, each time adapted to the specific situation.