Ideally, each piece of information is stated OnceAndOnlyOnce, because its the system designer made it so you DontRepeatYourself (the titular DRY). If you have duplication in code, the two can get out of sync. And they do. Often. Disastrously so. On the other hand, there are cases where duplication is not so great a negative. * For example, ''this text'' that you're reading lives on Ward's server, but you're reading a copy of it. This is rarely an issue. ** One time this duplication proves problematic is stale copies: if you download it, and I change it to ''that text'', you'll have to reload to see my change. This negative could be mitigated by creating a mechanism to push updates to the web browsers viewing it. *** At that point, there would still be a problem, albeit a rarer one: if you were in the middle of an edit when I save my changes, your edits will be on an outdated copy. **** So, we could prevent users from indiscriminately saving over top of other edits by some sort of token to declare the version on which the edit began, then refuse to save if that isn't the latest version. Note that WardsWiki doesn't implement this, but Wikipedia does. ***** But, you'd still be annoyed about the inability to save. So, we could design some sort of locking mechanism that notifies you that I'm in the middle of an edit, warning you of potential conflicts. This example is typical of the LongTail of problems that you chase when you're trying to simulate true DRY, but still, at some point, it's AsGoodAsDry. And I wonder how far this could go. What if you noticed two areas of code that depended on a shared meaning: ''in foo.rb'' obj.secret_code = 53 ''in bar.rb'' if 53 == obj.secret_code ... Now, this is obviously pretty heinous programming to begin with. But if you came across it and weren't in a place where you could stop what you were doing and write tests then refactor? What if you had a mechanism like: ''in foo.rb'' # ConNascence with bar.rb obj.secret_code = 53 ''in bar.rb'' # ConNascence with foo.rb if 53 == obj.secret_code ... Then you could have a tool, like a PreCommit check, verify that any blocks of code following such a tag would prompt you to verify the Evil Twin blocks have not been negatively impacted. This isn't great, but is it AsGoodAsDry?