I’ve seen a few attempt to promote reuse within organizations, and they all failed because they assumed a non realistic communication model within the organization. In some cases the approach was completely naive: just because some code had been written to address a specific problem, everybody was supposed to know about this code. There's only one organization capable to achieve such level of coordination: it's called "The Borg". They have a collective intelligent and are continuously in sync, one and another.
This type of information sharing simply does not happen in nature.
A more sophisticated approach involved use of repositories and/or knowledge management system to promote information sharing in a common tool. I've seen most of these approach fail as well. Having a common repository to share the information is generally a good idea, but expectations on those systems were really high, and probably unreasonable.
The starting point to promote code reuse within an organization is to know that there is some code that already solves your problem. From a communication perspective we have Developer A, a potential writer of an information at time T0 who knows something about what he's currently doing. Some times later, or maybe simply somewhere else, we'll have Developer B with a similar problem, at time T1. To have a successful communication:
- A should have written something meaningful about the problem he solved
- B should have searched the repository for an existing solution
- B should have found what A wrote
- B should have recognized that what A said was relevant to his problem
I personally find structured systems for storing information particularly bad: they force users to choose where to file their data, and the way people label their knowledge varies a lot form person to person and from time to time. Non-structured information repositories, such as Wikis with a Google-like search tool are definitely better, but they don't solve the core of the problem.
Sometimes we can connect our specific problem to a more general case, for example a "shortest path problem" or a "traveling salesman". This is probably how we'd call the problem after we've found the solution. The way we describe the problem before might be a lot different. Knowing how to call the problem is already a step towards the solution. This means also that who describes the problem and who describes the solution might use different terms. making our asynchronous-remote-decoupled communication at high risk of being completely ineffective.
Effective communication about partially unknown problems needs a higher amount of feedback. That's what we do when reading the menu in an ethnic restaurant: or (closer to our example) when we get into a shop to buy things we've seen but we don't know the name. A clerk might have a gotcha and tell us "Ah! you meant this!" showing us what we wanted and telling us how it's called. The most effective way to communicate about unknown things is the one with more feedback: face to face conversation.
Unsurprisingly, organizations trying to push communication through structured systems are often the ones that put a lot of efforts in preventing effective face to face communications to happen. Well ... in fact preventing good things to happen is one thing organizations are good at. And effective communication is one of these fragile things which might happen in a good environment, but there's no way to force them to happen.