Return to Answer

Though I agree with @GregBurghardt's answer in general that for library development in larger organizations one has to scale the organizational infrastructure with all the measures he mentioned, to my experience, there is a middle ground for smaller teams, which does not require to "replicate the open source community inside ones organization", at least not in full . In case

• the group of people accessing a common library is small (5 to 6 persons at most)

• you have shared code ownership for the team (so anyone can fix bugs on the libs)

• you have tools for reverse-lookup where in the whole code base a certain library and/or library function is used (so anyone who starts to change something in a lib can make an impact analysis beforehand)

then a certain amount of library/framework development is possible and manageable without causing too much hassle. Of course, you have to bring up some discipline to follow a few strategic and tactical rules:

• "small is beautiful"! Don't put things into common libraries "just in case" - only put code there which was used at least two or three times somewhere.

• ideally, put only stuff into a lib where the API can be kept highly backwards compatible, and avoid incompatible changes to function signatures or function semantics

• if there is code which brings in 3rd party dependencies, make sure will be kept in separate libraries, so noone will be forced to introduce a dependency they don't need

• more general: don't be tempted to throw too much stuff into a "commonlibrary" dumpster. Keep your libs clearly separated by topics and responsibilities.

Some of the points on Greg's list most teams should already have in place today, regardless whether they develop common libs or not, so it is not necessarily extra effort. For example, automated builds and a CI system, to make sure noone accidentally breaks the build (and in case this happens, each team member should be able to fix that, regardless if the bug is in a lib or elsewhere). Automated tests are also helpful, but usually it is sufficient to use the tests your team has already written for the software based on the common libs, so this also might not cause too much extra effort.

However, the larger the number of people working with these inhouse libs gets, the more management and communication effort will be needed. At a point where you split one team into two, to allow them more individual development, you have to decide whether each of the teams will have their own "common library", or if the extended communication and maintenance effort is still balanced by the time and effort saved through reusage.

Though I agree with @GregBurghardt's answer in general that for library development in larger organizations one has to scale the organizational infrastructure with all the measures he mentioned, to my experience, there is a middle ground for smaller teams, which does not require to "replicate the open source community inside ones organization", at least not in full . In case

• the group of people accessing a common library is small (5 to 6 persons at most)

• you have shared code ownership for the team (so anyone can fix bugs on the libs)

• you have tools for reverse-lookup where in the whole code base a certain library and/or library function is used (so anyone who starts to change something in a lib can make an impact analysis beforehand)

then a certain amount of library/framework development is possible and manageable without causing too much hassle. Of course, you have to bring up some discipline to follow a few strategic and tactical rules:

• "Small is beautiful"! Don't put things into common libraries "just in case" - only put code there which was used at least two or three times somewhere.

• Avoid developing large "frameworks", which too easily get interlocked with the applications depending on them. They often suffer from exactly the issues you mentioned in your queestion.

• Ideally, put only stuff into a lib where the API can be kept highly backwards compatible, and avoid incompatible changes to function signatures or function semantics

• If there is code which brings in 3rd party dependencies, make sure will be kept in separate libraries, so noone will be forced to introduce a dependency they don't need.

• More general: don't be tempted to throw too much stuff into a "commonlibrary" dumpster. Keep your libs clearly separated by topics and responsibilities.

Some of the points on Greg's list most teams should already have in place today, regardless whether they develop common libs or not, so it is not necessarily extra effort. The most obvious thing is state-of-the art version control. Moreveover, automated builds and a CI system are pretty standard today, to make sure noone accidentally breaks the build (and in case this happens, each team member should be able to fix that, regardless if the bug is in a lib or elsewhere). Automated tests are also helpful, but usually it is sufficient to use the tests your team has already written for the software based on the common libs, so this also might not cause too much extra effort.

However, the larger the number of people working with these inhouse libs gets, the more management and communication effort will be needed. At a point where you split one team into two, to allow them more individual development, you have to decide whether each of the teams will have their own "common library", or if the extended communication and maintenance effort is still balanced by the time and effort saved through reusage.

Though I agree with @GregBurghardt's answer in general that for library development in larger organizations one has to scale the organizational infrastructure with all the measures he mentioned, to my experience, there is a middle ground for smaller teams which works with only a fraction of the effort. In case

• the group of people accessing a common library is small (5 to 6 persons at most)

• you have shared code ownership for the team (so anyone can fix bugs on the libs)

• you have tools for reverse-lookup where in the whole code base a certain library and/or library function is used (so anyone who starts to change something in a lib can make an impact analysis beforehand)

then a certain amount of library/framework development is possible and manageable without causing too much hassle. Of course, you have to bring up some discipline to follow a few strategic and tactical rules:

• "small is beautiful"! Don't put things into common libraries "just in case" - only put code there which was used at least two or three times somewhere.

• ideally, put only stuff into a lib where the API can be kept highly backwards compatible, and avoid incompatible changes to function signatures or function semantics

• if there is code which brings in 3rd party dependencies, make sure will be kept in separate libraries, so noone will be forced to introduce a dependency they don't need

• more general: don't be tempted to throw too much stuff into a "commonlibrary" dumpster. Keep your libs clearly separated by topics and responsibilities.

Some of the points on Greg's list your team should already have, regardless wheter you develop common libs or not, so it is not some necessarily extra effort. For example, automated builds and a CI system, to make sure noone accidentally breaks the build (and in case this happens, each team member should be able to fix that). Automated tests are also helpful, but usually it is sufficient to use the tests your team has already written for the software based on the common libs, so this should not cause too much extra effort.

The larger the number of people working with these inhouse libs gets, the more management and communication effort will be needed. At a point where you split one team into two, to allow them more individual development, you have to decide whether each of the teams will have their own "commom library", or if the extended communication and maintenance effort is still balanced by the time and effort saved through reusage.

Though I agree with @GregBurghardt's answer in general that for library development in larger organizations one has to scale the organizational infrastructure with all the measures he mentioned, to my experience, there is a middle ground for smaller teams, which does not require to "replicate the open source community inside ones organization", at least not in full . In case

• the group of people accessing a common library is small (5 to 6 persons at most)

• you have shared code ownership for the team (so anyone can fix bugs on the libs)

• you have tools for reverse-lookup where in the whole code base a certain library and/or library function is used (so anyone who starts to change something in a lib can make an impact analysis beforehand)

then a certain amount of library/framework development is possible and manageable without causing too much hassle. Of course, you have to bring up some discipline to follow a few strategic and tactical rules:

• "small is beautiful"! Don't put things into common libraries "just in case" - only put code there which was used at least two or three times somewhere.

• ideally, put only stuff into a lib where the API can be kept highly backwards compatible, and avoid incompatible changes to function signatures or function semantics

• if there is code which brings in 3rd party dependencies, make sure will be kept in separate libraries, so noone will be forced to introduce a dependency they don't need

• more general: don't be tempted to throw too much stuff into a "commonlibrary" dumpster. Keep your libs clearly separated by topics and responsibilities.

Some of the points on Greg's list most teams should already have in place today, regardless whether they develop common libs or not, so it is not necessarily extra effort. For example, automated builds and a CI system, to make sure noone accidentally breaks the build (and in case this happens, each team member should be able to fix that, regardless if the bug is in a lib or elsewhere). Automated tests are also helpful, but usually it is sufficient to use the tests your team has already written for the software based on the common libs, so this also might not cause too much extra effort.

However, the larger the number of people working with these inhouse libs gets, the more management and communication effort will be needed. At a point where you split one team into two, to allow them more individual development, you have to decide whether each of the teams will have their own "common library", or if the extended communication and maintenance effort is still balanced by the time and effort saved through reusage.

Though I agree with @GregBurghardt's answer in general that for library development in larger organizations one has to scale the organizational infrastructure with all the measures he mentioned, to my experience, there is a middle ground for smaller teams which works with only a fraction of the effort. In case

• the group of people accessing a common library is small (5 to 6 persons at most)

• you have shared code ownership for the team (so anyone can fix bugs on the libs)

• you have tools for reverse-lookup where in the whole code base a certain library and/or library function is used (so anyone who starts to change something in a lib can make an impact analysis beforehand)

then a certain amount of library/framework development is possible and manageable without causing too much hassle. Of course, you have to bring up some discipline to follow a few strategic rules:

• "small is beautiful"! Don't put things into common libraries "just in case" - only put code there which was used at least two or three times somewhere.

• ideally, put only stuff into a lib where the API can be kept highly backwards compatible, and avoid incompatible changes to function signatures or function semantics

• if there is code which brings in 3rd party dependencies, make sure will be kept in separate libraries, so noone will be forced to introduce a dependency they don't need

• more general: don't be tempted to throw too much stuff into a "commonlibrary" dumpster. Keep your libs clearly separated by topics and responsibilities.

Some of the points on Greg's list your team should have, either, if you are have common libs or not. For example, automated builds and a CI system, to make sure noone accidentally breaks the build (but in case this happens, each team member should be able to fix that). Automated tests are also helpful, but usually it is sufficient to use the tests your team has already written for the software based on the common libs, so this should not cause too much extra effort.

The larger the team gets which works with these inhouse libs, the more management and communication effort will be needed. At a point where you split one team into two, to allow them more individual development, you have to decide whether each of the teams will have their own "commom library", or if the extended communication and maintenance effort is still balanced by the time and effort saved through reusage.

Though I agree with @GregBurghardt's answer in general that for library development in larger organizations one has to scale the organizational infrastructure with all the measures he mentioned, to my experience, there is a middle ground for smaller teams which works with only a fraction of the effort. In case

• the group of people accessing a common library is small (5 to 6 persons at most)

• you have shared code ownership for the team (so anyone can fix bugs on the libs)

• you have tools for reverse-lookup where in the whole code base a certain library and/or library function is used (so anyone who starts to change something in a lib can make an impact analysis beforehand)

then a certain amount of library/framework development is possible and manageable without causing too much hassle. Of course, you have to bring up some discipline to follow a few strategic and tactical rules:

• "small is beautiful"! Don't put things into common libraries "just in case" - only put code there which was used at least two or three times somewhere.

• ideally, put only stuff into a lib where the API can be kept highly backwards compatible, and avoid incompatible changes to function signatures or function semantics

• if there is code which brings in 3rd party dependencies, make sure will be kept in separate libraries, so noone will be forced to introduce a dependency they don't need

• more general: don't be tempted to throw too much stuff into a "commonlibrary" dumpster. Keep your libs clearly separated by topics and responsibilities.

Some of the points on Greg's list your team should already have, regardless wheter you develop common libs or not, so it is not some necessarily extra effort. For example, automated builds and a CI system, to make sure noone accidentally breaks the build (and in case this happens, each team member should be able to fix that). Automated tests are also helpful, but usually it is sufficient to use the tests your team has already written for the software based on the common libs, so this should not cause too much extra effort.

The larger the number of people working with these inhouse libs gets, the more management and communication effort will be needed. At a point where you split one team into two, to allow them more individual development, you have to decide whether each of the teams will have their own "commom library", or if the extended communication and maintenance effort is still balanced by the time and effort saved through reusage.