Common libraries in a large team

Question

Assume you have five products, and all of them use one or more of the company\'s internal libraries, written by individual developers.

It sounds simple but in practice,

Answer 1

I agree - this is difficult. In our small team (consulting .. not a product company - which made it harder), we had one common component that stood out from the others. In this case the recipe for success was:

• Make a good developer responsible for developing the component
• Make a good developer the gatekeeper for maintaining the component
• Make sure all upgrades (there were several) are backward compatible
• Make sure there is some basic documentation (or a simple reference application) explaining how the component is to be used
• Make sure all developers know that the component exists (!) and where they can find it (along with the code, if they wish to review it)

Give developers the ability to review the code and suggest better implementations or refectoring, but have the final mods go through an experienced gatekeeper. When the component were upgraded, older apps did not have to upgrade. If we did a new release, we evaluated if we wanted to upgrade, and if we did, all we needed to do was swap the libraries - no code needed to change, unless we wanted to use some new features available through the upgrade. Resistance is inevitable, but sometimes it is a good sort of resistance when it comes from good developers who have better ideas for a new generation or refactored component.