Dave Thomas says, "Don't Repeat Yourself, or 'DRY,' says that every piece of system knowledge should have one authoritative, unambiguous representation. A system's knowledge is far broader than just its code. It refers to database schemas, test plans, the build system, even documentation."---xj40dkcfea73---Dave Thomas says, "Don't Repeat Yourself, or 'DRY,' says that every piece of system knowledge should have one authoritative, unambiguous representation. A system's knowledge is far broader than just its code. It refers to database schemas, test plans, the build system, even documentation."

Read this interview with Pragmatic Programmers Andy Hunt and Dave Thomas:

http://www.artima.com/intv/dry.html

Here's another excerpt:

Andy Hunt: Creating a code generator is an investment. You're banking that it will be cheaper in the long run to build the code generator, because as changes come up you can simply tweak the input to the code generator and regenerate the byproducts. Without a code generator, you will have to manually make changes by hand each time to all the byproducts. If you expect a lot of volatility, a code generator can be a good investment.

Dave Thomas: In fact, I'd go further. Typically, if I build a code generator, chances are good I will generate the products manually first. And only when I come back to it will I say, "I'm now in a situation where I need to automate this." That approach has two benefits. First, I might never come back, in which case I don't have to write the code generator. If I do come back, I've already validated the code generator's output. So I don't just march off into the unknown, I actually aim at a definite target.

What do you think of Andy and Dave's comments?

One thing I always struggled with is trying to use this when it comes to documentation and especially requirements which involves several stakeholders to a project. I had high hopes for the XML format in OpenOffice and to use it together with Alistair Cockburn's use case templates. In this way one could let the requirement people change the requirements in OpenOffice and then extract the changes they make to design artifacts, test plans etc.

Checking upon the XML format, I couldn't find a easy solution. So I wonder what are our experience with applying the dry principle when used with artifacts used by non technical stakeholders.

I think to talk in this way about orthogonality is somewhat misleading. Andy Hunt defines orthogonality as "...things that are not related conceptually should not be related in the system". This implies, that things either are or are not conceptually related otherwise this principle wouldn't be very helpful. However, this clean separation is unreal. Orthogonality exists only with regard to a purpose. In any non-trivial system, there is always more than one purpose. You have conflicting purposes and the real challenge for any software designer is to deal with those.

For example:

Purpose 1: We want to be able to change different layers of the system independently. Data lives longer than applications. Business rules live longer than user interfaces. There can be different user views on the same data. There can be many appolications that use overlapping data sets. So keep datamodel, business rules and UI separate.

Purpose 2: We want to make changes in only one place. Very often, when a new field is added to the database, it is because our concept of a certain entity type has chanced. For example a Person gets a hair_color field. Every person has a hair color, so when we add this field, we want it to show on the UI in many places where a person is viewed or edited and we want it to be included in a Person class that enforces business rules.

Although these two purposes may not be equally important in every system, they do exist both at the same time. Now, if someone tells me to do it in an orthogonal way and to not repeat myself, that doesn't tell me a lot about how to proceed. Of course there are ways to deal with this problem but when I look at all the object persistence frameworks, I see that people take decisions as to which purpose they prioritize. These decisions are everywhere. Object orientation itself talks about encapsulation, which means nothing less than to tightly couple access methods to data. This may be a good decision with regard to one purpose but a very bad one with regard to another.

My example was taken from technical architecture. But the harder ones are conflicting user conceptions of some problem domain. Unfortunately it is not always possible to find out _the right one_. We have to live with overlapping purposes, overlapping contexts and conceptual models and we must recognize that orthogonality and DRY have an expressiveness comparable to the advice: Always do the right thing!