On the Web-Techno.net site there's a new tutorial posted that talks about the DRY principle in development (Don't Repeat Yourself) and why you might be misunderstanding the intent.

I know what you are thinking: "Again a boring article on DRY? Don't we have enough already?". You might be right. However I see too many developers (junior or senior) applying DRY like they are doing some witch hunting. Totally randomly or everywhere they can. So apparently we never have enough DRY principle articles on Internet.

A little reminder for those in the back who don't follow: the DRY principle means "Don't Repeat Yourself" and was first introduced in the The Pragmatic Programmer. The principle itself was known and applied before this book came to life. However the Pragmatic Programmer defined it precisely and put a name on it.

He starts by defining the original intent of the principle: not repeating knowledge (not necessarily repeating code). He gives an example of a e-commerce site and the logic around "shipments". If there's logic around these shipments happening in multiple places in the application, that can lead to maintenance issues down the line. He suggests creating a single instance of the knowledge about shipment handling rather than just reducing code duplication. He gives an example of a product instance and code duplication happening in some of the data validation. After showing a possible solution for this particular issue he gets into some issues that come from over-DRYing your code including useless abstractions and premature optimization.

In this new post to his site Mathias Verraes approaches the concept of the DRY principle (Don't Repeat Yourself) as being more about knowledge. He includes two "real world" examples where the business rules can change around you.

“Don’t Repeat Yourself” was never about code. It’s about knowledge. It’s about cohesion. If two pieces of code represent the exact same knowledge, they will always change together. Having to change them both is risky: you might forget one of them. On the other hand, if two identical pieces of code represent different knowledge, they will change independently. De-duplicating them introduces risk, because changing the knowledge for one object, might accidentally change it for the other object.

In his examples, he shows how hard-coded rules (like "a product container can only contain 3 products") could just be around certain needs, not the entire range of requests. He covers some of the principles of Domain-Driven Design and how they apply here, pointing out that changing rules in one part of the application can have an effect on other parts depending on it.