The costs and benefits of reusing software code

Custom software development is expensive, certainly if you include the cost of the need to maintain lines of code over time. A common strategy is therefore to reuse code that has been created already or share the development and maintenance costs between different parties.

Different types of reuse

Reuse models can differ the types of software assets to reuse:

  • Requirements,
  • Architecture patterns
  • Design patterns
  • Binaries
  • Code
  • Unit tests
  • Interfaces
  • Etcetera

When you are sharing requirements, designs or ideas, the benefits are there for you to take and any drawbacks are there for you to overcome and modify as you require. As soon as you start to reuse real code or binaries however, you will need to think about the dependencies you create towards the reusable asset. These dependencies can be more costly than you think and potentiallly can slow you down. When reusing code, libraries, SDK's or binaries you will need to make decisions about the  dependencies reusing the asset imposes you immediatly and in the future

  • Design time dependencies, for examples those related to versions of technology choices, language, operating systems, protocols
  • Compile time dependencies
  • Install time dependencies
  • Run time dependencies
  • Supplier dependencies
  • Organisational dependencies
  • Archive structure
  • Ownership models
The cost & benefit models for reuse differ for each of these different ways. In this article i will concentrate on
  • Non-modifiable:
      API through SDK
  • Modifiable:
      Single code base, Single owner
      Single code base, Multiple owners
      Multiple code base, Single owner
      Multiple code base, Multiple owners

With a single code base and a single owner.

Possible merits of reusing software code

Most mentioned and expected advantages are:

  • Savings of effort and thus money
  • Faster time to market
The benefits for time to market can, under the right conditions, be  substantial as the following picture illustrates. Rather than to go through a long own development path with 'just' the efforts to reuse a software asset can be acquired of a much bigger value: 

This looks great but there are boundary conditions which need to hold:

  • The software asset does exactly what you need it to do, it complies with your functional requirements
  • The software asset has been tested and is mature, it complies with your non-functional requirements
  • The software asset does not have dependencies

Costs of reusing software code

In practice in turns out that the benefit from software reuse are less big than most managers and some architect expect because the costs of sharing are quite high. First lets look a bit closed to reuse benefit. Suppose you need a certain software asset. If that asset is not available and you need to create it from scratch, i will cost you a certain effort. But if that asset is already available, for example as a library you can buy, an open source component or a reusable asset created by another department in your company, you still have the cost of reuse:
The cost of reuse include finding good candidates:
  • Identifying possible components to reuse
  • Identifying the match between candidate components and your functional and non-functional requirements
  • Testing a few components such that you can identify the match
If you have good candidates then there are the cost of modifying, testing and integrating the component:
  • Modifying the components functionality to fit your need
  • Testing the component to your users usability, performance, and reliability requirements
  • Modifying the code to your platform and tooling requirements

Benefits of reusing software code

In the following picture you see two products, A and B. They both have lines of code which are unique to their product, product A specific LOC and product B specific LOC, and they have a potential for sharing, the reuse potential. From the picture you can see visually that the maximum sharing benefit a company can have is equal to the reuse potential.

Unfortunately this is not for free. As we saw above there are costs of sharing:

  • Cost of integration of the common component
  • Cost of defining the exact boundaries and required functionality of the common component
  • Cost of engineering communication overhead

So if, $C_C$ = Effort representing the common overlap in product A and product B $C_S$ = The cost of sharing the common asset in a  product Then the maximum beneficial value of reuse for that product, $V_R$ is: $V_R$ = $C_C - C_S$ If a common asset can be 'consumed' in multiple products, the total benefit in terms of saving effort is $N \dot {C_C}$ minus the total costs of sharing $\sum_{i=1}^{N}C_{Si}$ $TV_R$ = $N \dot {C_C} - \sum_{i=1}^{N}C_{Si}$ Note that this formula can only have positive value when the cost of sharing are not higher than effort it takes to create the common asset, don't reuse if the reuse potential is too small!

How does this develop over time?

There are a few possibilities in how a common component  will develop over time:
  1. The common component will remain fully common
  2. The common component will be gradually 'poluted' with product specific logic
Which scenario will unfold is difficult to predict: it largely depend on different factors:
  • The commonality of the product roadmaps
  • The commonality in the timing of the need for common features in these roadmap
  • The quality of the engineers creating the code
  • The understanding of the product needs and commonality by these engineer
If these factors are not well and professionallity managed, the component can seem common but in practice the common component contains a lot of product specific code. As the time progresses, the benefit decreases:

Conclusions and recommendations

When considering functionality for reuse between 2 or more products take into account that:
  • The common component has a substantial size
  • The common component should have a common roadmap
  • Product management should be made aware their role to explicitly marking the need & expecations for commonly developed features
  • Software engineers should be trained to understand the product needs before assuming there is an explicit need for common features.

No Comments, Be The First!

Your email address will not be published.