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:
- there might not be enough awareness. the extra effort of finding;
- the reuse is not valued appropriately
- 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.