«This class is unusable. I have reprogram it from scratch.» Does that sound familiar to you? – To me it is something I heard over and over again from my developers. Resulting in having five or six implementation of an autocomplete widget. All coexisting in the same code base.
Of course this is wasted time. Redoing the same work is against the DRY principle. Code is not being reused.
Why did they not use component XY and instead reprogrammed its functionality from scratch? Here’s the answers I got:
- «I didn’t know that the component XY existed»
- «The component XY is too complicated to use it»
- «What does it do anyways?»
- «I don’t know how to use it»
- «It does not work»
There’s one technology where code reuse works very well. It’s the jQuery plug-in system. In fact I doubt there is anyone using jQuery without using any plug-in. Why’s that?
In this blog post I’d like to analyze why you never have to convince a developer to use a jQuery plug-in. I learned a lot on encouraging code reuse from the jQuery ecosystem.
«I didn’t know that the component XY existed»
When the developer tells you that he didn’t know that someon already programmed a component fulfilling a certain functionality it’s because of a lack of promotion. In jQuery there’s one central plug-in directory which is fount at well-known location. Every jQuery user knows where to look first when looking for some functionality. The directory is being promoted at a prominent location on the jQuery homepage.
So when you want to have your components reused,
- create a directory
- promote the directory – in team meetings, via your internal mailing list etc.
«What does component XY do?»
When the developer has to decide whether to develop something from scratch he is doing a “make or buy decision”. He weights the benefit of using the existing component against the cost of learning how to use and maintain that component.
In jQuery what helps me making this decision the live demonstration of the component. Every jQuery plug-in is required to have a demo (Example from qTip). I’ve seen this strategy in other technologies as well. MongoDB has a online shell where you can try the technology without having to install it first. It’s basically a “try before you buy” offer. Try and get addicted before you go through the painful process of installing, learning and configuring the component.
«It’s too complicated!»
Using the component should not be complicated. The learning curve must be steep. The “user interface” has to be simple. The simplicity of the interface for jQuery plug-ins is obvious. Here’s how to use the jQuery-Fancybox plug-in:
$(element).fancybox()
Does it get any simpler? Zero configuration. Immediate results. The cost of seeing first results is minimal. The developer has a positive first experience.
I try to do the same with the components I want to be reused: A simple interface. They should deliver results without having to configure something first.
«I don’t know how to use it» – Documentation
This one is obvious. The component needs good documentation. A good jQuery plugin like Fancybox offers:
- a tutorial to get the developer started quickly
- a reference – API documentation
- a support forum
Why not doing the same for components you develop internally?
«It does not work» – Quality
Of course the component should have a high quality and deliver the promised results. I am mentioning this at last because IMHO the jQuery plugins are not a very good example for this. The spectrum in terms of quality is very wide. There are plugins with very high quality like jqTouch. But some are just ugly hacks. Nevertheless: The reputation of jQuery plugins in terms of quality is high. So usually you get what you expect.
To have code reused, the quality of the code needs to be high. I try to ensure high quality through unit tests, code reviews and last but not least good developers.
To wrap this up, here’s how I would encourage code reuse:
- Ensure an easy to use interface
- Provide good documentation
- Provide a demonstration
- Ensure good code quality
- Promote the components
