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 duplicatio

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...