Last update   PvD

Software Reuse

Considering that developing good software takes a lot of effort and time, and copying is virtually free, it seems a logical thing to reuse previously developed software components in new developments.  However, software reuse hardly occurs;  it has proven to be a very precarious subject.  For that reason reuse is viewed as the 'Holy Grail' of software development.  Why ?

The major cause is the way most software is developed:  in projects under time and effort constraints.  No project manager will spend time and/or effort to make candidate components reusable as it won't bring this project any advantages;  making components fit for reuse is left to the project which could use any of the components.  So the documentation is minimal, the next project is unaware of these candidates for reuse and/or sees a lot of problems with the specific components (understanding it with little documentation, 'not invented here' syndrome), so it is not happening.  What can be done to improve this ?

First we have to consider whether we really want to apply software reuse, because it takes extra effort initially and we must have confidence that it is worthwhile.  The advantages are considerable:  reliable components –documented and all– ready for use.  The disadvantage is the extra effort to make a component more general, and to test and document it thoroughly.  When the other projects are developing something completely different, reuse is probably not applicable.  However, when the other projects are developing similar software or software for the same problem domain it makes sense.  Potentially this could be upgrading an existing product with new capabilities.

Mind you, we are not talking about a solution for the same problem in the same context –which can be achieved through copying– but about similar problems in a similar context:  it requires the definition of a domain.  The standard requirement by the marketing department for a 'flexible' solution is understandable, but when no indication is provided as to what range should be covered it is useless (similar to the concept 'optimal').  Consultation with potential customers is practically a requirement.  The definition of the proper domain is paramount, as becomes clear in the list below.

Software reuse is possible at three levels:

  1. Concept level (patterns):  eases design, reduces design and development risks;
  2. Model level (architecture):  top level design has basically become superfluous, probably some function blocks (modules) can be reused after adaptation;
  3. Code level:  here reuse really pays off, but platform and interfaces must be stable and almost identical.  Minor adaptations are acceptable, but preferrably use wrappers (don't adapt the generic code but add a conversion module for an interface).

It is a good idea to start applying reuse in the above order.

To actually apply software reuse, three areas must be tackled:

Software reuse is not a scientific problem but a practical one.  That doesn't make it any easier or cheaper.  Experience suggests that it takes a factor 3 effort to make a component reusable.
Software reuse is not to be confused with Component Based Development (CBD), which is an iterative method to develop software.  It is related but CBD puts the emphasis on the development process, not on reuse.

See also Software Documentation.