Stop Solving Solved Problems: Escaping the Cycle of Duplicated Code

Source: Dev.to

It’s a scenario that plays out in countless offices and home offices every day: a software developer stares at a tricky problem, cracks their knuckles, and begins architecting a solution in their mind. They envision the modules, the APIs, and the elegant lines of code that will slay the dragon. Days, or even weeks, later they emerge with a working solution, proud of their creation, only to discover (or have a colleague point out) that an open‑source library or internal tool already does the exact same thing.

Sometimes the existing tool is even better than what the developer built.

This phenomenon is the source of a well‑worn joke in the industry: “Every time a developer encounters a problem, they start building a solution, completely missing that it already exists.” While it’s funny, the reality behind it is a costly and frustrating cycle of duplicated effort. It’s a multifaceted issue rooted in psychology, corporate culture, and sometimes a lack of training. It’s often summarized by the pejorative term “Not Invented Here” (NIH) syndrome.

The Case for “Proudly Found Elsewhere”

The cost of this duplication is staggering. It’s not just wasted development hours; it’s the compounded cost of maintaining multiple, slightly different implementations of the same thing. Every bug fix has to be applied in multiple places. Every new developer has to learn multiple systems. Over time, the software ecosystem becomes bloated and brittle.

A cultural shift toward “Proudly Found Elsewhere” is essential. This mindset prioritizes solving the business problem over the personal satisfaction of writing every line of code. It recognizes that standing on the shoulders of giants—whether they are open‑source maintainers or a team in the next building—leads to faster delivery, higher quality, and more sustainable software.

How to Build a “Proudly Found Elsewhere” Culture

Moving past NIH syndrome requires a conscious effort from both individuals and organizations.

For organizations: Build a marketplace, not a black hole

• Make code easy to find and easy to use.
• Invest in internal component marketplaces where teams can publish libraries with clear documentation, usage examples, and versioning.
• Foster a culture of collaboration where teams are encouraged to discuss technical challenges and share solutions.

For organizations: Incentivize reuse

• Change the metrics.
• Reward engineers who contribute to internal libraries and those who choose to reuse them.
• Celebrate projects delivered faster and with fewer bugs because they leveraged existing components.

For developers: Ask “Why not?” before “How?”

• Before writing a single line of code for a common problem (e.g., logging, authentication, data validation), habitually search for existing solutions.
• Ask teammates, check the company wiki, and look for open‑source libraries.
• Assume the solution already exists until you can prove otherwise.

For developers: Contribute, don’t fork

• If an existing library covers 80 % of your needs, avoid building the remaining 20 % from scratch.
• Consider contributing the missing feature back to the original project or extending it with a plugin.
• Improving an existing tool is almost always better than creating a new one that will have to be maintained forever.

The Nuance: When Reinvention Is the Right Choice

Reinventing the wheel isn’t always a bad thing; sometimes it leads to innovation. As developer Lea Verou has argued, using a massive, bloated library for a tiny fraction of its features can introduce significant performance overhead and long‑term maintenance costs. If you only need 5 % of a library’s functionality, writing a small, purpose‑built function might actually be the smarter choice.

For example, parsing a few lines of simple Markdown for bold text and links doesn’t necessarily require a 1,700‑line library. A small custom function might do the job more efficiently and with far less complexity.

The key is intentionality. The goal is to stop accidental or arrogant reinvention of wheels—the kind that happens because a developer didn’t look, didn’t ask, or didn’t care. By shifting our focus from the pride of creation to the satisfaction of solving real problems efficiently, we can escape this costly cycle.

We should celebrate finding the perfect existing solution just as much as we celebrate building a new one from scratch.