Effective Software Reuse

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.

About Hayim Makabee

Veteran software developer, enthusiastic programmer, author of a book on Object-Oriented Programming, co-founder and CEO at KashKlik, an innovative Influencer Marketing platform.
This entry was posted in OOD, Software Reuse and tagged , . Bookmark the permalink.

6 Responses to Effective Software Reuse

  1. Shahar Ron says:

    SOA is my favorite form of reuse. It actually doesn’t really reuse the code since only one instance of the code run which is inside the service but the BL the code represent is reused.
    I think basic infrastructures should be shared code (DLLs). Things like logging, configuration, error handling, wrappers for communication, file access and such. Almost everything else should be services.

    In other words I agree and even restrict your approach that the infrastructure team which serve everybody write shared code (meaning really linked/included) but almost nobody else should. –

  2. Nir Rotshtein says:

    I think that the article left out one important aspect: Most components that are developed internally in the company fail to be reused because they are bound conceptually to a specific application domain.
    To create a reusable component you need to specify its goal and functionality in general terms and to think how users outside of your company can use it.

  3. nygaardravn says:

    Reuse happens at many levels, ranging from a method used several times within its class, to basic tools and extensions to a programming language class library (such as those found in com.apache.commons.lang for the Java programming language), to inhouse domain-specific components, to public (web) services, and many more.

    Each type has its own scope of reuse, and its own set of constraints and options affecting viable approaches to development, dissemination, and maintenance of reusable software.

    Because of this I see no “one size fits all” approach to software reuse. Rather, each scope level (single class, module, subsystem, application, team, department, company, business domain, programming platform, …) could benefit from an “RCT”, but what that would mean, and what responsibilities it would have, would be a very different from one scope level to the next.

  4. Hadas says:

    I’m facing a chalange of conducting a RCT team for an internal client (another team in the company) that has a succefull saling product and thus requiers Very FAST solutions (or else they just implement the missing components themselvs).
    The client team is starting to fill much pressure and therefor the need for an RCT team was raised. (In a perfect world the order would be the other way arround).

    I myself am expirianced and believe It is possible to have an RCT team that makes good, robastic Components and at the same time meet tight sceduals (rolling components that evolve with time)
    but I’m having a hard time convincing my team that keep insisting that without having a LOT of time planning each component, the solution will not be good.

    What is your opinion? Is it possible to have a good RCT, starting from basic components that meet time and basic requirments – and that evolves with time?

    • makabee says:

      Hadas, I believe that in general reusable comments always require more planning.
      Since they have many potential clients, it becomes more difficult to change them after they have been deployed.
      If you need to provide fast solutions, you must first define the minimal required functionality.
      However, you must also plan how the components will evolve, and this must be taken in consideration in the design.
      I think that one technique to do that is to first define multiple interfaces, each one covering a different aspect of the functionality, and then implement them gradually.

  5. Putcha V. Narasimham says:

    Reuse applies mostly to components but in principle it is also applicable to any artifact of software development including any of the UML diagrams, test cases, test data, descriptions etc. Yes, they need to be developed and refined from time to time to maximize use and reuse.

    For this I proposed Cooperative Software Artifacts Repository–COSAR. I would like to mail it to as many interested professionals as possible. Let me have your email IDs.

    Best wishes,


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s