Why shouldn't I have a single monolithic utility library?

Question

We've got a few common libraries (C# but I guess this isn't platform- or language-specific), let's call them A, B, and C. Library A has references to B and C, library B has a reference to a 3rd-party DLL, and library C stands alone. The idea behind three separate projects was that each library had distinct functionality, but library A has over time become a more or less "catch-all" common library that most every client app references. Only a few apps reference B and/or C without A as well.

We're trying to improve our source control conventions, and one thing we're trying to do is properly tag and release these library DLLs, so client project files can point to a static version of the code instead of the always-changing trunk. This is proving a bit convoluted - for example, a client project that references both A and B. A itself references B, so there are technically two references to B coming from the client project.

So the obvious thing seems to be to just combine everything into a single common/utility library with well-organized namespaces. As I said, almost every client app references one of these libraries, so who cares? Doing this won't introduce any undesirable situations with 3rd-party dependencies, and all our target machines are internal and maintain roughly the same environment/software configuration.

This seems too easy of a solution though, so I figured I'd at least get a second opinion. An alternative could be to use the GAC and strongly sign/version everything. Am I missing any catches here?

Answer 1

I think you're right consolidating into a single library.

Very often code is componentized into too many deployable units whereas the logical piece of functionality seems to be the criteria for separation. This is wrong IMO. Assemblies should be aligned with the deployment scenarios and release cycles instead. Otherwise you end up with a horribly complex dependency graph where anyways every assembly is managed, built and deployed together.

Interesting question though! Let's see what other people think :)

Answer 2

This is a classic "Goldilocks and the 3 Bears" problem.

You don't want a single monolithic library - and you don't want too many libraries. You want exactly the right number of libraries :) Not too many, not too few, just right.

There are reasons for having different libraries:

1) Independence of development - the libraries can be developed independently. 2) Smaller deployable

I think that a general rule of thumb might be if there is a separate team that is dedicated to doing full-time development on a particular section of the library, it should be separate. If multiple teams add a few bits of code here and there every now and then, then there should be no issues with independence of development and deployment and you might as well have a single common library. It sounds like this is the case in your situation, so go with a single library.

Another question to ask is "What problem that we are currently experiencing would splitting up the library solve?" If it doesn't solve any problems, then no need for separate libraries.