This article on InfoQ summarises the way I feel about code reuse.
I’ve worked for a few organisations that have fallen for the code reuse trap. It goes something like this. A smart bunch of well meaning developers write an application. Along their travels, they realise that some of the code they are writing is generic enough to be of use to other projects and thus the common.jar is born (or worse yet, framework.jar). The package ends up being a bucket for common services (e.g. EmailService, AuthenticationService), base classes (e.g. AbstractDomainObject, BaseHibernateDAO), utility classes (e.g. StringUtils, FileUtils) and configuration (e.g. log4j.properties). The project finishes and everyone is happy about having created some reusable code.
Sometime later, along comes another bunch of developers to work on the next great killer application. They notice all the great work done by the first bunch and go about importing common.jar into their project. However, they soon realise that EmailService is missing some features that they need, AbstractHibernateDAO doesn’t work with the new version of Hibernate, etc. So they go about enhancing and adding to common.jar, while carefully managing the dependencies on the first application to make sure they haven’t accientally broken it.
Several months, years and projects later common.jar has grown out of control. There are now 10 projects dependent on it. Making any change to it is a bit of a nightmare, requiring regression testing and sometimes changes to the dependent projects. If projects are running in parallel, common.jar becomes the battleground of merge conflicts. Fear grows and each project now starts avoiding changes to common.jar, which can lead to interesting hacks and workarounds.
Analysis at this point would probably show that any one of the 10 projects only uses about 10% of the capabilities provided by common.jar so the value of the reusable component has been diluted and the pain of managing the dependencies far outweigh any benefit provided by reuse.
So, be wary of code reuse. The cost of building several EmailServices pales into insignificance when compared to inefficiencies introduced by having to manage complex dependencies.
Recent Comments