For many years Software Reuse has been seen as a solution to both reduce the costs of software development and improve the quality of the systems being developed. However, in practice, most companies today have the feeling that they are not enjoying the full potential of software reuse.
In general, the most successful type of reuse today is the one exploring third-party components, in the form of libraries and frameworks. It is hard to imagine that someone would implement an application to parse some standard file format like XML, or to implement some standard communication protocol, without first looking for libraries that already provide the required functionality.
In contrast, a more difficult type of reuse is the one of components developed inside an organization. This happens because very often the components being implemented as part of an application are not planned to be reusable.
The effective development of reusable components requires a serious investment, including:
- The design of the component’s interface, that must be both rich and generic.
- The implementation of the component’s functionality, that must be efficient and independent of the application.
- The full testing of the component’s behavior, that must take in consideration a great diversity of contexts.
- The detailed documentation of the component’s usage, that must guide its potential users providing all required details.
- The indexing of the component in a shared repository where it can be easily found.
In my opinion, this can be achieved only by a team that is dedicated to the development of reusable components. This team should receive requests from the product teams in the organization, with the description of components they would like to have in their applications and that are considered good candidates to become reusable components. Ideally, the communication between these teams should include the participation of a software architect, who should be responsible for approving the requests.
The biggest challenges of the Reusable Components Team (RCT) are:
- Understanding the requirements from different product teams so that the components developed are really reusable across different applications.
- Creating new components according to the time schedules of the product teams, respecting their deadlines and avoiding any delays in their plans.
- Being responsive fast enough when the product teams ask for changes or extensions in existing reusable components.
Therefore, the product teams are the clients of the RCT. The product teams should treat the components developed by the RCT as-if they were third-party reusable components, and never duplicate the code or change it by themselves.
From my experience, if the RCT is not able to meet its challenges, being responsive enough and fast enough, the product teams will “take ownership” of the reusable components, creating their own versions and ruining the very idea of software reuse.
Good luck with your reuse plans, I will be glad to hear about your own experience.