How does your organization handle common components?

Question

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.
• ...

Answer 1

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.

Answer 2

We're trying to move toward more service-based systems, so that if we create a particular functionality for one project, it can be used from another project through a web service. This way there's only one instance of the code.

Naturally this works better for some types of components (an example: we recently created a PDF creation service) than others (probably overkill for a string manipulation utility).

Answer 3

The only successful component I have seen around here is redistributed in a compiled version (*.dll). Users report bugs and request features directly with the owning team, and they implement them themselves. There is an api for writing your own plugins for stuff that is the most likely to change, so people can extend the functionality in many cases.

There is always the trade-off to

• convince people to use your component
• keep a reasonable level of quality at the same time

Not sure what is the best thing to do in your case, but in general try to implement the core logic yourself, keep the component configurable/extendible so people don't need to change the core all the time and offer good support. For some reason some developers always tend to reinvent the wheel however stupid it is, so I wouldn't worry about it too much.

Answer 4

A good way is to institute periodic code reviews. During these if you find a wheel re-invented you can use the opportunity to either educate the developers to use to common component or why they felt the need to re-invent it and ally their reasoning to the original code. This way everyone's requirements are made and the components are improved for everyone.

Answer 5

Treat them the same way you would third-party libraries. I wouldn't even let the other teams see the source - doing so can lead to a lot of time-wasting criticism and back-biting.

Answer 6

How big is the organisation? I've seen this stuff handled very well in a small organisation (a few dozen programmers total) where one or two individuals are known to have ownership of each component, and are responsive to feature requests.

It's easier to march off to someone's office (or mail them), explain what you need, and get one of:

• the expected way to do what you want,
• agreement to add the required feature (or direct a minion to do so),
• permission to implement the required feature in the common component,

Than it is just to launch into writing workarounds, starting a fork, or writing an equivalent new component. If your programmers are smart, they'll do what they think is easiest. The trick is to ensure that this is the right thing.

Aside from really simple stuff like linked lists, there wasn't a whole lot of wheel-reinvention going on. There were, very rarely, private forks for particular products, most commonly to reduce code size by chopping things out. But the usual way to do that was to modify the original component to have more build options.