"If you are developing a component to be reused elsewhere in your enterprise, don't just design it for the job in hand, design it as though it were going on sale in the open market - to a bunch of customers that you'll never meet and whose requirements you will never know"

If you want to know how to maximize your reuse count, take a look at how the most successful component authors in the world do it: -

Many people put their effort into trying to make reusable components out of the highly specific business logic in the core of their applications, dismissing none-core infrastructure elements as "low-value". Experience shows us that the most reusable parts of an application are not usually found in the core of the application but around its perimeters. For example, the highly specific code that drives the relationship between the ordering and stock control processes in your online order system is unlikely to achieve many reuses if componentized. On the other hand, that email management piece is going to be useful in every new application that you write from now on. Components with horizontal appeal will always achieve greater reuse than vertical components, a fact borne out by the make up of components in today's open market.

If you develop components to meet the requirements of a particular project, your efforts will likely yield components that fail to cover their subject area completely. Potential consumers of your component are unlikely to have the same requirements as the component's original customer and thus potential consumers will reject the component as a bad fit. If you were writing for the open market, you would aim to cover the subject area completely in order to meet the needs of all your perceived future customers.

When developing your components, try and isolate them from any implementation specifics that your initial project may impose. The best example of this type of problem is the database. If your application is Oracle based and you allow that implementation dependency into your component, you will instantly dismiss all of the possible reuses from users of other databases. Try to keep the reusable portion of your components generic and implement an application specific adapter layer that takes care of implementation specifics.

People will not look for a prewritten solution to a trivial problem. Capturing the highest quality knowledge while still keeping to the above criteria will lead to the highest demand. The decision to reuse a component is based upon the cost of developing equivalent functionality in-house. Whilst packing a high volume of man day effort into the component inflates its value, this is more easily dismissed than increasing its value through high complexity (and therefore high cost) man effort. This is because designers and developers always underestimate the time needed to write any given function. If a component represents a functional area whose complexity puts it outside the reach of other development teams then it will be reused very often indeed! This is why graphical components like grids, mapping tools and charting components are always in the bestseller list at ComponentSource.

Whilst it is tempting to fill you components package with nice-to-haves and frills in the belief that you are adding value to potential reusers, the effect of your efforts will actually be the opposite to that intended! The most successful components in the open market are those that meet their goals and do no more. Extra functionality reduces the proximity of the match between component and requirements and thus creates a barrier to reuse. Furthermore, users believe that the over-specified component will impose unwanted inefficiencies on their final application.

Imagine your component were going on sale, in its own right, to the general public. You would use nice meaningful method and class names and you would finish that help file wouldn't you? There's no point in creating highly desirable chunks of functionality if know one can figure out how to use them or what they do without a two week training course. Endowing your components with commercial quality finishing maximizes their reusability.

In summary write for the open market. If you are developing a component to be reused elsewhere in your enterprise, don't just design it for the job in hand, design it as though it were going on sale in the open market - to a bunch of customers that you'll never meet and whose requirements you will never know. This will help you to achieve all of the goals set out in this article and, in turn, to maximize your reuse count. Who knows, you may even be able to sell your components at ComponentSource!