Sunday, May 1, 2011

When is it okay to customize a library?

I was working on an issue the other day and I noticed some Javascript libraries being used had been customized. Meaning the person who changed the library was not the author and/or is not a contributor on the originating project. Immediately it felt dirty. When is this okay?

In the particular instance I was working on, the Javascript library was a jQuery history module for remembering and refreshing page state given Ajax calls. Simple stuff, but the plugin was old, not in active development, and frankly didn't work (I might write this up later). The link in the comments for the project page didn't even exist.

So what do you do in this senario when dependent site functionality is not working correctly? Do you (1) patch the plugin or customize it, or (2) replace it?

The right answer is (2). The plugin is out of date is isn't working correctly, it needs to be removed and all dependent code updated to use something that does work.

I did (1) due to timing. I put in fixes into the plugin, added some clean up code to fix the issues. The fixes were very narrow to the problem scope. However, I still felt dirty.

I realized, in general, I don't ever want to do this. Sure, sometimes you might to just need to get the job done, I've been there. However, the "module" should be self contained and untouched. The module should be used, not embedded in your solution. You need to be able to update it and remove it if needed. If there is truly an issue in the plugin, open a bug on the project page, submit a patch and get the next release. Otherwise, fix the problem outside the module.

I also realized version management in Javascript modules isn't so easy within another project. Especially when you download the sources locally. If it works, why update it? Well actually, there is a reason that software is "released" over and over again. It has fixes and enhancements to make it better. Therefore, usage of that module will get better as well, verses just working. Same reason you make updates in your own projects.

These are general problems in Java as well (and everywhere else). We download source JARs, add them to our projects, and then we customize it. Those base JARs are also released with updates, but the base remains.

I then thought, how is this prevented, why don't people update libraries in their projects? Because it's talked about before hand and the "risk" factor is involved. Talking about this out load with senior folks on a project, or with your project manager, and worry will soon come. It's nobody's decision but technical folk to change something like this. Don't involve people who should just be users in the discussion. You will get talked out of bettering your changes, or simply overruled because the impact will seem high and too risky, verses doing the right thing for the long term.

To summarize, don't customize your libraries being used in your projects. Update them regularly or replace them when needed. Seems like simple advice, but I haven't seen it done well in any projects I've worked on.

No comments:

Share on Twitter