A common component is a library or some other piece of code that is created and maintained by one group and used by many groups.
Some problems we have are:
- The users don’t report issues with the components.
- Users build workarounds to the components to suit their needs.
- They break compatibility with the trunk version just to meet their deadlines.
- Users end up coding their own (less robust) solutions because they think it’s better.
How does your organization handle common components?
Ideas that I have:
- Treat the component like an open source project and require teams to submit patches.
- Totally disallow custom modifications to the code.
- …
What you have here may be a human factors problem rather than a technical one. In fact it may be primarly a learning issue (coupled with the typical not invented here syndrom).
Having worked in large companies, I realise that it is tough for a new person to understand all the resources (i.e. shared code libraries) available to him, much less how and when to properly use them.
When you have a new hire, is he/she given formal training in your common component library?
Then there is the problem of what people are rewarded for. At review time do managers reward people for using the common components, improving them and submitting improvments back to the library? Or do managers simply care about their own projects.
As for your group that maintains the common library, what form or reconginition do they give to people who take the time to suggest or submit improvements? Do they get written up in the company newsletter? Get a cash bonus? Get their photo on the bulliten board?
Remember, people are highly unlikely to do something for a company for which they receive no recognition or reward.