During the last decade, the gap between the demand for new, complex software systems and its supply has widened. This gap and the difficulties faced by software engineers in bridging it have been described, some decades ago by Dijkstra as the Software Crisis: systems have become so large and complex that creating software for them is increasingly more difficult to complete on time and within the constraints of the project budget.

Software reuse is then of growing importance as a major factor in alleviating some of the problems resulting from the Software Crisis.

At first glance, software reuse appears a natural way to develop software, but in practice this does not happen. The challenges are numerous and require a fresh approach to the entire range of activities involved in the engineering of software. Every time new software is needed, developers tend to write it from scratch rather than harness components developed through previous projects.

In the first four decades of computer history the emphasis was on hardware developments, but now the emphasis has shifted toward human concerns. In the mid-1950’s, 90 percent of application costs were devoted to hardware but now, at least 90 percent of these costs are software. This reversal reflects not only the decline in hardware costs and the increase in programmer salaries, but also the recognition that systems must be carefully designed and developed to accommodate human users.

Software is essentially a symbolic product. It differs from the vast range of other products produced by conventional engineering techniques. Software, once designed, has no manufacturing phase and does not deteriorate, although changing environments will usually require software modifications.

The most often cited reasons why software is not reused are:

• lack of tools to support a developer in trying to reuse components
• lack of training for developers to create reusable components and to use reusable components
• lack of an educational methodology and motivation towards reuse and its benefits

The fact that software reuse has not been widely accepted questions the suitability of existing management practices, organizational structures and technologies involved in the development of software.

In short, a rethink of the software development process is long due.

Whatever the next software development breakthrough will be, it must be supported by strong asset reuse techniques.

Like any other engineering discipline, software engineering can gain a lot from a solid discipline of reuse. But unlike other engineering disciplines, software asset reuse does not come naturally in software engineering. When it does, it never comes without costs and risks.

Possible reusable asset categories:
- Requirements / Specifications
- Documentation
- Designs
- Architectures
- Source Code
- Test Data
- Executable Code

Software asset reuse starts by being a cultural thing. Managerial aspects play a critical role in it. Software asset reuse cannot happen without strong commitment from the managerial structure of the development organization.

Reuse Libraries and DSM (Domain-Specific Modeling)

We can consider two types of reuse libraries: Horizontal and Vertical.

An horizontal library augments the expressive power of the language without commiting to a specific application domain. It has the advantage of being useful across several projects, but it is limited to around 20% of the application’s total code.

A vertical library contains domain-specific components, and can reduce the amount of coding we need to produce by up to 65%. The drawback is that it can only be used within a single application domain, and hence potentially few projects

If we map these two types of libraries to the DSM paradign, we can say that an horizontal library lies on the solution domain, and a vertical library lies on the problem domain.