Questions to consider before moving to a shared library

When a software organization reaches a certain size, with many different projects all running at once, inevitably someone realizes multiple project teams are writing code that seem to serve very similar pressure. This is usually followed by an attempt to bring together all this code into a library, managed by a single team.

This is an easy initiative to pitch. Software best practices already recommend avoiding code duplication, so you get all the technical benefits like fixing bugs in only one place, and spreading the cost of development across multiple clients. And of course, there's the financial aspect of it, where developers can instead work on other things instead of rewriting the same functionality in a different context. Sometimes code merging can be seen as so intrinsically good that it's impossible to even suggest that maybe it shouldn't be done.

The other factor that makes it difficult to argue against code merging is that the drawbacks, while real, are mostly intangible, and very difficult to put an exact price on:

This is not to say whether it is or isn't worthwhile to merge software projects. It's simply a call to have a more informed dicussion about the true costs and benefits. Also, it's a call to better evaluate the outcome of any merging projects. If you only look for data showing your project was a success, then that's the only thing you'll find. Talk to all the people involved, including both management and developers, including both library team members and client team members, and try to do a qualitative assessment, in addition to the typical financial only assessment.

If you do decide to go ahead with a merge project, here are some questions to consider. There aren't any right or wrong answers. Instead it's meant to make sure all the groups are in general agreement about the responsibilities of everyone involved, and to provide a framework for hammering out workflow issues.

For concreteness, the following questions use a game engine as the code to be shared, and assumes separate "engine teams" and "game teams," the latter of who do the implementation for a specific game. It's easily generalizable to other software uses (web developers can substitute "web framework" and "web app" if they like).

Version 1.0 (April 2019)






by Yosen
I'm a software developer for both mobile and web programming. Also: tech consultant for fiction, writer, pop culture aficionado, STEM education, music and digital arts.