There have been a great deal of evil introduced to the world in the name of code reuse. I imagine one of the things feeding into this is code reuse always sounds like a good idea to a non-technical roles.

Engineer: I’m making a helper to localize link’s alt text.
Manager: Good idea. Will it be re-usable?
Engineer: Ur… Yes?

From a management perspective reuse almost always looks like efficiency. If you can write it once and use it everywhere it’s a no-brainer. As an architect I often find myself explaining to business stakeholders how combining things which appear similar is a bad move. The idea really doesn’t resonate.

Now if you’re a programming tools shop you’re creating software to be reusable by default. But if your software is a means to an end, and that end is a production site, there’s frequently no return on the investment. Making a component truly reusable is a non-trivial effort, it places a larger burden on the logic and configuration, and it also creates a new common place where you must regression test very distant and different applications when you make a change.

Let’s say it take five times more effort to make a component reusable. Will you really use it five times? The second time you use it will the assumptions made up front even fit the need? Taking a look at your existing code how many places have you ended up with reusable components that got used once? How much more difficult to maintain is that component than if you had basic code that did it’s job in-place?

Now I do agree fully with all of the best practices and design patterns that are part of the modern software development culture. Love them in fact. Strong separation of concerns, components interacting at only one degree of separation, ensuring components can be tested outside without their normal run-time context and dependencies. But those aspects aren’t related to re-use - they’re related to software design.

What I am a big fan of is tactical deduplication in software. If you need something, write it once and write it for the context in which it’s needed. If you need something again bring up the existing code and compare it to the new situation. What’s easier - refactoring the previous instance in a way that can be used from both locations, or creating a new implementation patterned after the previous one but implemented directly for the different context and needed logic? If there’s more effort and more risk using literally shared code then going down the reuse path is almost always the wrong thing to do.

“But how can you say that? That’s not a proper application of computer science this and object orientation that. Common functionality should be extracted into a shared base class at the very least.”

Nope, computer science doesn’t trump pragmatic application. Just like third normal form in databases.

The best database schema is the one which can efficiently realize all of the critical execution patterns needed by the application. When that’s at odds with normalization the textbook takes a second priority. The same is true with software design - the goal of patterns and practices is to create software that functions properly and is efficient for engineers to create and maintain. If code reuse doesn’t have a tangible positive impact on creating and maintaining your software then it shouldn’t be done because it’s correct in some intangible way.

Plus, and here’s the kicker, when you do create a shared component it will be the second (or third) time the need arises rather than the first. So a) you know for a fact this is something that will actually be reused, b) you have the experience of the implementing the component at least once before so the shared reimplementation be done from a point of much greater understanding of the problem, and c) you have at least two real-world places where the component will be used which is invaluable in understanding what different needs will be in different contexts.