Software Reuse

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:

Concept level (patterns): eases design, reduces design and development risks;

Model level (architecture): top level design has basically become superfluous, probably some function blocks (modules) can be reused after adaptation;

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:

Specifications: the candidates for reuse must be identified and their functionality (range, coverage) specified. The individual components get the life of an autonomous product: individual documentation, test sets, versioning, etc. Note that apart from the calling interface, a module has also an interface towards the underlying resources (platform).
Mentality: the mindset has to change from 'not invented here' to 'how to solve the problem by assembling' ready-made components ('better well stolen than poorly invented').
Organisation: to support the development of the components independent from actual projects, and to encourage the mentality change.

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.