How do you foster the use of shared components in your organization?

Question

If your company or project places an emphasis on (or at least appreciates) the development of code and components that can be reused and shared across projects, what are the "social engineering" things you've needed to do to facilitate the re-use the code?

In my experience, code or components that are simply stated as being "reusable" won't be reused unless that code has someone to champion or evangelize it. Otherwise, people simply won't know about it.

How do you make sure shared components or reusable code work in your organization?

Answer 1

In my organization, we had management help to foster the creation of a shared library. We also indoctrinate new hires to use it.

Then, we put good code that must be reviewed by everyone for usefulness and completeness. This is where the group buy in comes into play.

Also, we have a very robust, documented process for branching the shared lib for use in Visual Studio. Hint: we use svn:external property to manage checkouts from different repositories in the same folder structure. Potential shared code first exists in the branches before it gets promoted to the trunk.

Answer 2

A couple of thoughts come to mind:

• Make them very well documented and easy to figure out. That way, no one will give up on using them because its too confusing.
• Make them very useful, and make sure they take care of problems that are so annoying that people would have to be crazy not to use them.

Another great tactic is to find out what code other people in the organization have in their projects, offer to extract some of that functionality (talk it up about how great it is and how you really want to use it in your project). Once their code is added to the shared module, you usually end up +1 fan of the shared library, and have an evangelist to help you sell the idea. Remember, people usually only do things if they are in their benefit - so making them look good and their code look good is strongly in their benefit.

Answer 3

The best way I've found to make people want to use your reusable code is to show them how to use it the way you intend. Provide a sample program using your library. Keep it in the source code repository just like any other project. Keep the sample program documented and updated when the reusable library changes.

Answer 4

Personally I try and demo code that I think is useful and give a comparison between using it and not using it to try and show why it's so much better. Normally this happens during weekly development meetings.

I agree that it really needs someone to evangelise and push for the adoption of new methods, one of the things I've found a lot of developers to not be that great at is selling themselves or what they've done, so it's worth working on these skills and pushing others to do the same, leading by example.

Answer 5

This may be a bit java centric; but publishing both binary and source in a corporate maven repository does wonders for visibility. It makes other people happy to use your code ;) We work with a lot of open source and find that ready availability of source code to read is really a key feature, especially when it can integrate directly into the IDE. We really expect that from in-house projects too! I wonder how we managed before we had maven ?? (Even ant can use a maven repo nowdays)

Answer 6

In a grad school class a few years ago, I did a case study on a web-based repository where programmers could deposit their code for re-use. This wasn't for my workplace, but for a lab with thousands of scientists, & engineers where there wasn't any other centralized means for sharing.