One way IT factories can really hurt themselves and their companies is by underemphasizing, or not considering at all the notion that systems and components should be designed with “reuse” in mind.
What is reuse, or the Reuse Model?
The basic premise behind the Reuse Model is that systems should be built using existing components, as opposed to custom-building new components. The Reuse Model is clearly suited to Object-Oriented computing environments, which have become one of the premiere technologies in today’s system development industry.
Within the Reuse Model, libraries of software modules are maintained that can be copied for use in any system. These components are of two types: procedural modules and database modules. When building a new system, the developer will “borrow” a copy of a module from the system library and then plug it into a function or procedure. If the needed module is not available, the developer will build it, and store a copy in the system library for future usage. If the modules are well engineered, the developer with minimal changes can implement them.
The notion of reuse is really just a means of carrying the notion of object-oriented development to design. Instead of reusing classes and methods, we may be reusing entire systems – databases, services, or applications.
Here are a few benefits of the key benefits of reuse:
- Improve ‘time to market’ by reducing analysis, development and QA cycles.
- Reusing elements increases the return on investment for the initial creation of the reusable component.
- Better quality product with fewer defects. Defect density is lower when reusing a component that has already survived the QA gauntlet and is working in production than with a newly developed product.
- Reuse increases productivity. If considerable portions of a system are already developed and in place, it stands to reason that a smaller project team will be required than for new work. This frees the stakeholder to increase his shop’s productivity by either assigning those resources to other work that wouldn’t have been possible otherwise, or to cut costs by reducing headcount.
When designing systems, these two principles should be kept in mind:
- Design TO reuse. Software design should first seek out functional, reusable elements and leverage those components and modules to as great an extent as possible.
- Design FOR reuse. If reusing a currently available component is not feasible, design architects should seek to create components or systems that will be conducive to future reuse.
For some other “light reading” on the topic of reuse, take a look at these articles:
