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

Duplication is the root of all evil

I would argue that unchecked government is the root of all evil :)

I do get a lot of flack for even suggesting that duplication should be an option. I understand why, but let me complicate this a bit.

Say you have a fairly large library that doesn't actually do anything in particular - it's just a collection of utilities. There are NO tests for this library - at all. You need only one function from it. Say, something that parses out a file's extension.

Pop quiz: do you just write something as small as this in your own project, or you bite the bullet and use the free-for-all untested set of utilities, which WILL break your application if someone breaks the function?

Also, imagine you are in environment where writing tests is not part of the culture, since most projects are very intense and have a very short development span.

Duplicating large systems - such as client registration - would be dumb beyond belief, of course. However, aren't there any cases where it is safer to duplicate something fairly small in your project if the alternative is not safe enough (no system for maintaining common code).

Think of it this way - and this happens all the time - multiple contractors working on different projects, for the same company. They don't even know about each other.

My argument is this:

If a team cannot dedicate to maintaining a solid common codebase, or if the environment does not give them enough time to, it's best to let them work as separate "contractors".

You will STILL need to use large existing systems that simply cannot be duplicated.