As programmers we’re taught to constantly look for opportunities to reuse. The mantra being less duplication of effort meaning less work. Backed up by the DRY principle and just about every book on programming it can be difficult to take the opposite stand: Keeping things separated. The criteria used for reuse is often the same. Things look structurally similar so they are the same thing. And since you shouldn’t repeat yourself reuse it!
As an example take the case of an elastic search index used to populate a web page and introducing another web page that needs the “same data”. Great case for reuse of the index right? What if the data that is needed differs slightly by a few columns in the beginning. Maybe a few more columns in a months time. Developers reasoning about the page and the data will have a harder time since they have to juggle unrelated things. The structure of the data or code is one aspect and often the only criteria use for reuse. But more important differences potentially exist that dictates separation. On the first web page we might only present the data and on the second we might have to make certain columns full text searchable. Doing that will require more disk space and if that page is much less visited than the page that only presents we might not have the same requirements for replication for the sake of scalability. So what looks superficially identical turns out to be two very different things meaning reuse will introduce an dependency that hurts more than it benefits.
The Go programming language language has a nice little proverb:
“A little copying is better than a little dependency”.