Mark Needham

Thoughts on Software Development

Coding: Shared libraries

with 6 comments

On a few projects that I’ve worked on one of the things that we’ve done is create a shared library of objects which can be used across several different projects and while at the time it seemed like a good idea, in hindsight I’m not sure if it’s an entirely successful strategy.

I’m quite a fan of not recreating effort which is generally the goal when trying to pull out common code and within one team this seems to be a good approach the majority of the time.

When it comes to sharing across teams then I think we need to consider the perceived benefits a bit more because it doesn’t come without costs.

These are some of the types of code that we’ve shared previously:

Domain objects

I think this is the most dangerous type of code to share because although we often do have the same domain concepts in different projects, it’s quite rare that they mean exactly the same thing.

In addition there is an implicit coupling created with our database since we pretty much now have to make sure that our database schema matches up with the current version of that domain object.

Either that or we do have a shared database for all the applications which use that shared domain object in which case we have an even stronger coupling between applications.

We’re assuming that the two application have exactly the same domain concept and from my experience quite often that isn’t the case – even if there is a concept with the same name it may be used in different ways or mean something completely different in different applications.

This is quite similar to the problem with having a universal domain model which Dan points out in his classic SOA article.

In general I don’t think it makes sense to share this type of code.

Test code

This one seems like it should fairly universally a good idea – after all we often import 3rd party testing libraries so it seems like just sharing some common testing code shouldn’t be much different.

One piece of code that we shared was the Selenium bootstrapping code and this approach worked reasonably well until we wanted to adjust the amount of time between each command because commands were being sent to the browser before elements had the chance to load.

Apart from the fact that the other users of the library didn’t want anything change with respect to how they used the code we had to go and make the change in another project, build that and then update the reference that we had to the library.

Certainly this process would have been made easier if we’d used something like Ivy but the amount of duplication of code that we were saving didn’t seem worth the hassle it caused so we ended up inlining the code.

Infrastructure code

General infrastructure code e.g. code to handle NHibernate transactions which is quite unlikely to change seems one candidate which can work quite well in a shared library and so far I haven’t seen many problems arise from doing this.

I think the key with these bits of reusable code is that we keep them quite small and ensure that they have only one responsibility which will be useful for all the applications.

We eventually ended up slimming down our shared library and the majority of the code that remains in there is solving specific infrastructure type problems which will be the same across any applications using the same technical stack.

Things to be careful about when sharing code

One reason that we may share code is so that if there is a change then it only needs to be done in one place.

We need to have a degree of confident that if we put code in a shared library that this is actually the case.

If it’s likely that different applications might need shared code to change in different ways then we might not want to make that bit of code shared otherwise we’ll just end up with application specific code in a shared library.

From what I’ve noticed it makes most sense to put code which is unlikely to change and is generic enough to be useful across several applications as is into shared libraries.

For any other code it might actually be beneficial to accept that there will be some duplication between applications in the same organisation and not try and pull out a common piece.

Be Sociable, Share!

Written by Mark Needham

February 26th, 2010 at 12:36 am

Posted in Coding

Tagged with

  • INTPnerd

    The problem you mentioned you had in the “Test Code” section seems like a problem that is likely to come up any time you share code. There is always a chance that it will need to be changed in some way to be more flexible and accommodate more features or bug fixes.

    One solution to this problem that I thought of is kind of a middle ground where you are getting some of the benefits of sharing libraries (but not all of them) without the drawbacks.

    Here is how you do this. Lets say you are starting a new project and there are not yet any shared libraries from other projects and you want to start creating one. What you do is go ahead and create a separate library with the common reusable code, but keep it in the same source code repository in your version control system as the project you are currently working on. After you have released the first version of this project, create a new repository for the library you want to share. However this should only be a copy of the library and should not be connected to your project.

    Now when you start a new project and you want to reference this library, you actually want to create another copy of it in the repository for your new project. Keep it separate from the repository with only the library in it.

    Now you have two projects using a version of that library, but they are not obligated to keep up with or update the the library that has its’ own repository. If these two projects remain very active, you might choose to merge any changes in this library between that project and the library repository, but you don’t need to. If merging the changes becomes more trouble than it is worth you can stop at any time and let the projects start to have their own customized version of that library.

    I would expect that every project would have a point at which you will want to stop merging these changes when it starts to become less actively supported and you don’t have time to keep all your projects merged.

    With this model even if you never merge changes you still get the benefit of new projects benefiting from SOME of the work old projects have done.

    Like most things in software development it is not a totally black and white decision of either sharing or not sharing.

  • yeh you’re right I guess some of the problems would stretch across lots of different sharing scenarios.

    Actually I think the solution that you propose is quite similar to what we’ve eventually ended up with. Another problem that we ran ourselves into was having individual shared libraries when the common one started differing which was even more of a mess but thankfully we’ve got rid of those ones now.

    Also absolutely right about it not being black and white – I was just trying to see if there was any situations where it makes more or less sense to share code.

  • Pingback: The Morning Brew - Chris Alcock » The Morning Brew #548()

  • INTPnerd

    Hope I did not sound too critical. Overall a good post with some good points and good food for thought. Mainly I agree that if done incorrectly sharing code is often more trouble than it is worth. I also agree that the code needs to generic enough to be useful and generally don’t recommend sharing domain code. I was just trying to point out an alternative sharing strategy that alleviates some of the problems with sharing. I think if you are using this strategy then I disagree with what you said about only sharing code that is unlikely to change.

  • No it was fine, I’m not entirely sure about my opinion about sharing code so it’s interesting to hear other ideas as well.

    We’re trying out the strategy you suggest so it will be good to see if it helps reduce some of the problems we experienced with other approaches.

  • Pingback: Ultimate configurability at Mark Needham()