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 Nov 15 '19 at 13:08

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
| improve this answer | |

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.

| improve this answer | |
  • +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. – Greg Burghardt Nov 16 '19 at 1:21
  • 2
    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 Nov 16 '19 at 10:42
  • 1
    If the identitt provider follows a standard you wont need that library – Ewan Nov 16 '19 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.
| improve this answer | |

The quest for code-reuse is the holy grail that 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 and prefer to write our own code.

In fact, the problem is not technical: it’s cultural:

  • What worked very well so far is the reuse of patterns. We still feel free and craft the code. And it´s cool to reuse a pattern: everybody talks about it, and it’s in every advanced curriculum.

  • Another thing that works well is the use if standard libraries. Here, there is wealth of documentation about it 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.

The problem with custom reusable code is threefold:

  1. there might not be enough awareness. the extra effort of finding;
  2. the reuse is not valued appropriately
  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 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 than redeveloping. Offer opportunities to exchange on what already exist.

Now an idea that is not applicable in all context. But what’s more appealing than making 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.

| improve this answer | |

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.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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