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

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