>Such things as adding duplication to increase clarity is often papering over a problem, when it would be better to solve it.
So much this, lately. I've found myself unsatisfied with the convoluted code needed to share some functionality across two similar but distinct areas, and trying to figure out if the repetition or the convolution is easier to understand for the reader, and what it means for maintainability.
But really what's tickling me is that there is a better solution waiting in there somewhere.
Compare that with Go's "A little copying is better than a little dependency".
The problem with religious DRY is that the shared bits may eventually evolve into something that does everything for everyone, used everywhere, and becomes unmaintainable and buggy. You can't touch it without breaking something. The notion that tests will guarantee its correctness doesn't tend to work either since there's no way to cover all of a product's functionality via tests.
I think it's important to look at XP in context, see what issues it tried to address and how it tried to address them, and try to be pragmatic. There's certainly local situations where DRY is a good principle but generally you should strive to break your software down into independently maintainable pieces with well defined/small-ish interfaces, trying to stretch DRY across those boundaries would create problems (i.e. the dependency mentioned in that Go proverb).
So much this, lately. I've found myself unsatisfied with the convoluted code needed to share some functionality across two similar but distinct areas, and trying to figure out if the repetition or the convolution is easier to understand for the reader, and what it means for maintainability.
But really what's tickling me is that there is a better solution waiting in there somewhere.