Although our products often have the same requirements, the solutions are always developed anew. From different people, with different good results and different quality. A code library especially for the needs of our products seems to be a good idea.

I think the main problem would not be to develop this library, but to tell all programmers for which tasks there are already solutions.

In a small company like ours this is feasible, but how does it work in large companies? When you have large libraries, with several hundred methods.

How does a developer find out there that he doesn't have to develop a new solution for a problem because there is already a solution?

How is it prevented that an existing solution is accidentally developed anew?

  • 3
    Tongue in cheek : this is why you need SO TEAM solution. Please contact the sales now
    – Graviton
    Commented Nov 15, 2019 at 13:08

5 Answers 5


There are many ways of achieving this, but one of the most useful is code review, and it's something that's worth doing in an organisation of any size. All committed code should be reviewed by at least one other developer. They then give feedback to the original author, making suggestions on how it should be improved. These remarks may include:

  • possible programming errors
  • code where the intent is unclear
  • improvements to function/variable names
  • long functions/classes that should be broken down, and
  • code that duplicates existing library functionality

Code reviews and generally talking are good. But I would challenge the underlying assumption.

Try not to have shared code at all.

Really you only want to write the code thats unique to you.

If you have a common library, chances are there is already a 3rd party one that does the job better and is maintain by a bunch of people who; A. arent paid by you. and B. are dedicated to this one problem and making a resuable solution to it.

Trim your common libraries down to the point where they are no longer common.

"When you have large libraries, with several hundred methods."

Don't have these. Have small libraries that do one job.

"How is it prevented that an existing solution is accidentally developed anew"

Keep your software splits the same as your problem splits. ie Domain Driven Design or Microservices. If im working on a problem, im working on the code that is specific to that problem. I dont have to worry about other code.

  • +1 for pointing out the only sane method of code reuse in large organizations: reusing entire applications in the form of composable services. Any code that people rewrite is likely to be simple, and often tailored to that particular problem domain. Commented Nov 16, 2019 at 1:21
  • 4
    The answer glosses over the fact that company-specific libraries can still justifiably exist. For example, a package for accessing the company's identity provider (or any other company-wide resource, really).
    – Flater
    Commented Nov 16, 2019 at 10:42
  • 1
    If the identitt provider follows a standard you wont need that library
    – Ewan
    Commented Nov 16, 2019 at 12:07

There are many reasons why redeveloping similar solutions is a good thing:

  1. Your developers will have learned what not to do from earlier implementations. Repeating the same mistakes is going to make the development process slow, painful and expensive. Conversely, learning from the mistakes will make the next iteration better than the previous one.
  2. When reusing the library developers are reusing code, but what they want to reuse is experience. Until code is as flexible as our minds it cannot be as reusable as experience.
  3. Technical debt of green field projects start at 0. A common library would guarantee that the technical debt starts well above that.
  4. Interdependencies within a project is difficult enough to manage in non-trivial projects. Interdependencies between projects becomes painful very quickly. Basically you quickly eat up several FTE just coordinating between projects, patching the common solutions, and dealing with the inevitable fallout of breaking changes across your organization.
  5. Functionality that is common across your projects is very likely common across developers world-wide. Which makes it very likely that someone has already packaged it so that you can use it as-is rather than spending time developing it.

The only other thing that I can add is to basically recreate the open source community inside your organization. Focus on tight, small libraries and utilize package managers for your tech stack (NuGet for .NET, Maven for Java, NPM for JavaScript, etc). But then you need the infrastructure to support this community. That basically means something similar to GitHub or Azure DevOps, just to name a few. This will increase costs just to save some developer time, so it is a balancing act. Can you save enough developer time to offset the additional cost?

You would really need a large amount of shared code to make it worth the money and time maintaining this infrastructure. At this point it is more cost effective to go the route Ewan mentions in his answer, which is to decompose your code into reusable services.

Any "shared" code is likely to be library functions that are small, and few in numbers. Copying and pasting is almost easier and more cost effective.


The quest for code-reuse is the holy grail of OO programming since its inception.

Yet nowadays, we still rewrite over and over the same functionality again, because:

  • we are not aware that it already exists
  • we think that what exist is not what we need
  • we know it exist but are persuaded we can do better
  • we do not have the time to find out and prefer to write our own code.

The problem is not technical but cultural. Reuse worked well so far for:

  • design patterns, as we still feel free and craft the code. And it´s valued: everybody talks about it, and it’s in every advanced curriculum.

  • standard libraries, thanks to a wealth of documentation that facilitate their use. It’s included in the language training so there’s huge awareness. It’s well understood that standard libraries are more reliable than custom libraries. Then there is peer pressure to use it.

But for custom reusable code the hurdle is threefold:

  1. there might not be enough awareness of its existence. The extra effort of finding it, and understanding it does not necessarily pay off;
  2. the reuse is not valued appropriately. Writing additional code is more visible to peers and management;
  3. the reliability of internal code might not be valued at its legitimate value.

The first issue can easily be addressed via code reviews or and documentation. A lot of other answers address this point.

Unfortunately, the second and third are related to the people’s perception and the company’s culture. There’s nothing that you can do alone to overcome these issues directly, and miraculously convert people to new beliefs.

You need therefore to work on the value. Make it clear for people that reuse is valued by management more than redeveloping. Offer opportunities to exchange on what already exist.

Here another alternative: make the library a product (whether an internal product, an open source product or a real product added to your catalogue):

  • The knowledge of the library, the availability of documentation and the promotion will convey the right message to your employees.

  • The availability as a product makes it also clear that there is an incentive to reuse library components: not only are they thoroughsly tested, but using it promotes the companie’s own product with a success case if needed.

  • making your library a product will encourage colleagues to do tutorials, but aleo to raise the quality standards, thus breaking the hurdles of low quality.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.