Developing For Reusability
As software developers, we try to keep reusability in mind. To figure out whether a particular solution is reusable, take a look at what you have to do to use it. For instance, if you are developing an ASP.NET user control, does the developer who consumes that user control have to only write 2, 20, or 200 lines of code for it to work? If you create a custom server control, do I have to configure 5 settings for the bare minimum to work, or 100? Is your code a 1:1 correlation between the product code and the consumer code, or 1:100 (100 lines of product code for every 1 line the user of that component has to implement)? Is the setup easy to do, or is it too complicated? Is it very general or very detailed in setup?
Some solutions are labeled as reusable but require you to do as much work as the reusable component. In this situation, developing a wrapper around this component is a good idea. THis allows you to make the component more reusable by putting your implementation code and any common setup code in the wrapper, thereby saving extra coding effort. So in my previous example, 2 lines to reuse code is great; 20 is probably practical (unless the reusable code is 20 lines or less itself), and 200 lines to implement reusable code probably needs refactoring.
In this day and age, if it isn't simple to use, people won't use it at all.