Ayende Rahien (of the Rhino Mocks fame) wrote a post on his blog about “burning” Common/Utility libraries. I have to agree with his reasoning on why his Rhino Commons library should be “burned”. As I understand from his post it is a “garbage bin” or dumping ground for any random functionality that might be reusable. He pointed out that his library has very low cohesion, or in other words the library isn’t really focused on a fixed, finite set of responsibilities. Again, I agree with this reasoning.
However, I’m concerned that this might also encourage the other extreme: never creating common libraries and copying/pasting code from one project to the next! In my opinion, this is just as bad or even worse that having a common library.
Having a common library can be both useful and powerful, but it needs to be treated as its own project – or shipping product, if you will. Versioning, backwards-compatibility, proper API design, application of common API patterns, cohesion – these are just some of the things that you need to think of when designing a library. Designing a library requires at least one, if not more, architectural and design minded developers to really manage and ship a common library throughout its lifecycle. One thing often overlooked is deleting/obsolescing code, as well as reorganizing (or refactoring – what ever parlance you prefer) code into different namespaces and assemblies. Also, one must not shy away from moving library code into different Visual Studio solutions (or whatever solution/project system being used) or to different locations in your source code repository. Reorganizing applies not just to the contents of your library code, but also to how you work with your library code.
This is even the case with .NET itself. Granted, Microsoft doesn’t always get it right, but they’ve done a decent job. If you look at the Base Class Library shipped with .NET, there is a TON of functionality, broken into assemblies, namespaces, and types. This I think is very important when you are designing a library or suite of libraries – organization. How you break functionality apart, especially at the assembly level, can have a huge impact on the usability and perceived maintainability of a library.
I would argue that Common/Utility are not dead, but rather that is something that is difficult to do well and requires practice and disciple.