Making Reuse Work

What are the key principles, practices, and strategies to achieving significant levels of reuse?

Are the answers different for reuse within a project, within a business unit, within an enterprise, across industries?

To what degree do technology choices affect the level of reuse? Design practices? Business models? Incentive plans?

A big barrier to reuse is knowing that stuff exists that can be reused. How then does one go about creating a ReuseCatalogue?

Suggest you have a look at the SoftwareReuseBook. The standard measure is the reuse level R, which is defined as the ratio of "size of workproducts derived from reusable component systems" to "total application system size". How you measure "size" depends on the output of the process. There are other things you can measure such as number of defects, number of lines of code, or development time per function point or use case. The key thing is to look at the relationship between complexity and output (in terms of the eternal triad of time, quality and cost) as reuse is increased. -- AndrewJoyner

I've always been curious how you avoid the tight coupling problem with reusing components from separate projects. And if those projects are out of your control, you're screwed.

Internally, I've noticed that reuse is simple providing people have a good idea of most of the system. The problem seems to be making people aware of what already exists. Then reuse is a matter of refactoring.

But I'm guessing other people have done this better, like the DoIt team. I'd love to know.

This might be a stupid observation, but here goes... the biggest single thing that I tend to reuse over and over, in any language, is that language's standard library. Not only that, but the size and nature of a language's standard library determines a lot about what I can use the language for.

Would reuse be fostered if every organization had a standard library which was at least as well defined and ubiquitously accessible as the standard library in the language? Of course, care would have to be taken to ensure that it is well-organized, well-documented, and generally useful -- and that everybody is up to date. In particular, someone would have to consider submissions to the library, and reject those that are not sufficiently general to be of use to the organization as a whole. But if that care were taken, wouldn't it be worth it? -- EdwardKiser [modified Mon Apr 16 2001, 4:50 PM UTC]

: There's a paragraph relevant to software reuse at the end of http://c2.com/ppr/ams.html.

It strikes me that the things that get reused most successfully are not the "software ICs" sitting on the shelf waiting to be incorporated into a design. Instead, the software most reused is imbedded in the operating environment just waiting to be invoked -- e.g. the Windows API or Mac Toolbox windows, menus, buttons, and other widget-level features and objects.

I want to see a environment that offers reusable services at a level between widgets and full applications (ala creating an Excel or Word object). In the domain of business systems, the DoItFramework approach tries to facilitate this by defining a powerful, common and consistent user interface. This allows application-neutral shared services to be developed only once to provide presentation, retrieval, selection, analysis, query, classification, versioning, organization, navigation, etc., services for all enterprise IS needs. The products of business-process-specific development effort (data engineering, presentation layout design, defining relationships and association definitions) are also reusable. They are available to any other existing or new business process support by simple redefinition of the contents of any "worktable" in which relationships exist. Correctly implemented, integration falls out naturally, and enterprise services can be delivered in frequent increments, as a much more granular level than the (unnatural) "application" scope of today's efforts. --JimRussell

CategoryReuse