DRY or not DRY

I found a blog post recently that stated (among other things) that the author of that post considered the application of the DRY principle to create a dependency. As one of his highest values was to avoid dependencies, he often refused to do DRY-refactorings.

On first sight this sounds reasonable.

On the second it doesn't: If there is a place in your code that allows for a DRY refactoring, then that already IS a dependency! Remember that DRY tells us to have logic that means the same (=tries to accomplish the same) only once. So, if two places in code try to accomplish the same, they are implementations of the same requirement. If that requirement changes - well, there are two places to change in code making those two places linked. The problem with this is that it is usually not visible and thus easy to forget! The DRY refactoring (=extracting the code in question into a function) just makes that dependency explicit; it does not create a new one. Well, I certainly prefer an explicit dependency over an implicit one...

While I agree that not every DRY refactoring should actually be made; I think the dependency-argument does not hold...