DRY needlessly

DRY, don't repeat yourself, has become a battle cry to many in the programming profession. Wiping out all causes of spatial, temporal, and logical repetition is the aspiration of today's elite. However, zealotry has never suited me, and I tend to think that there exists good repitition as well as bad. Let's look at some examples:

First, Test-Driven Development is full of repetition. The tests and the code define the specification separately, but equally. Yes, you can make up all sorts of excuses for why there is duplication, but the fact remains that both the tests and the code are asserting the same thing.
Second, in Code Complete, Steve McConnell talks about the practice of using a function to check another function's work. For instance, if you are making some difficult calculations, you may wish to write a slow and steady function that you know works and then write a swift and dangerous function that you are unsure of. In debug mode you would run both functions and ensure the identity of the results.
Third, web programming often has client and server side validation of input parameters. Yes, I know you could write a control file and have both generated from that, but I seriously doubt that is a big enough win to justify the programming time involved. The duplication is accepted as useful.

In each of these cases, we're using repitition to enable a sort of "double-entry bookkeeping". We perform our work and then check our work to make sure everything balances out. The duplication is there for a reason, to ensure quality and correctness. The duplication that DRY is intended to eliminate is not there to support itself, but is instead needless. Think of it as a teepee. You have two sticks leaning different directions, supporting one another. There is repetition, you have two sticks instead of one, but they are working together and leaning on one another. This is the key, if you have duplication in your code, make sure the duplication is leaning in opposite directions.