I totally agree with Ayende Rahien about that creating Utils and Common-projects for re-use in other solutions are unnecessary. Out office is mainly working with one big client and they want to have a Common-library which is re-used in all their projects. We have refused to do this as there is a too big risk with how maintenance and updates would be handled for this library. We have instead tried to re-use successful patterns from previous projects. And if we need to re-use some code from another project we just copy it over to the new project.
By not using a Common-library and instead copy code from previous projects we don’t get a problem with maintenance and updates of the Common-library as each project is responsible for its own code. The risk for that there is bugs in the code which is copied is almost minimal since is has been used in production already and it’s most likely that the bugs have been found and been fixed. Also if you would need to change the functionality in the Common-library to fit your project this could introduce a breaking change for other projects, but if you have the code in your project you would not have to deal with this at all.
Of course there are benefits of having a Common-library but just the administration of it makes it a pain.
I got a brilliant comment from my former colleague Johan Slottner that I want to make sure that it will not disappear since I use HaloScan for comments.
Thank you Kjella for posting this one. I totally agree with you that the use of internal common libraries causes far more pain than it brings value to an IT organization. I have seen a number of those common libraries and all of them are facing the same problems:
- They are not fully reliable.
- Versioning is a pain, and there are several versions in use, and even several branches of the same common library.
- They are hard to learn, implying that is actually takes more time to get productive with the libraries than without them.
- Maintenance is abandoned, since there is simply no budget set to do maintenance.
- As they grow old, they rely on old technology, and nobody wants to put the effort to upgrade (due to versioning hell, and no budget).
So is there any time it is a good idea to develop internal commons? I have yet not found a good argument, but a few hints perhaps:
- Thinking of reuse probably makes the code better looking and easier to maintain in the project
- Sharing ideas and thoughts in the organization with links to where it is implemented is probably a good idea. The ideas can be copied, adjusted and partly reused.
- Service orientation may be the way to go to reuse business rules. It is easier to maintain a service than a library.
- Buying components may be a good idea if the component solves a common problem. But be aware of that even those components have to be maintained with respect to upgrades and licensing and thus require a budget.
Still, this is actually the first post I have ever read, that actually questions the use of commons. Everywhere I go, all praise the use of commons.
So, instead of using a common library you should focus on using patterns. Patterns will survive technology changes for sure!