Unveiling the Value of Reusable Components

Hello everyone, I'm Olga, and I'm a Product Engineer. I spend a lot of time mentoring people and generally talking about my work (even when no one has asked).

At one point, while explaining to a co-founder of a very nice project how we had set up a system of reusable components, I realized that for him, these were just words. "Reusable components" sounds great, but so what?

That's when it struck me: how to communicate the significance of this to people on the business side. And so, I told him:

The company pays for each component only once

That was when I saw the lightbulb go on in his head. He truly understood what I was trying to say. It also got me thinking, "Is there a way to quantify how much a company actually saves if the developers 'do it right'? Are there metrics for this? Formulas?". Let’s dive deeper.

Defining Component Reusability: From Basic UI Elements to Complex Structures

Before we dive deeper, let's clarify what we're talking about. My personal experience with component reusability stems from working with the React.js framework, but the concept can be applied to any kind of development.

What level of reusability am I referring to? Many developers working with React (or similar frameworks) are familiar with and their display systems, such as for example. A vast number of projects use Storybook, and you can take a look at their own libraries . Most of them include universal small components from which we can build larger structures — buttons, accordions, avatar components, etc. This is absolutely the right approach, but many projects go beyond this to have more complex reusable components, such as a profile component that you can use anywhere in the project or a profile popover component. Sometimes, entire pages are made up of reusable components.

Let's consider the example of a profile popover on GitHub:

In the screenshot, a profile component is shown which (as I would expect and as I would implement it) is a component that includes both frontend and backend elements and can be invoked anywhere in the project through simple code.

Something like:

import { ProfilePopover } from 'components/profile/popover';
import { Avatar } form '@ui/avatar';

export const SomeComponent = ({ user, lastCommitTitle }) => {
  const {id, username, avatarUrl} = user;
  return (
    <>
      // some code
      <ProfilePopover id={id}>
        <Avatar src={avatarUrl} /> {username} {lastCommitTitle}
      </ProfilePopover>
      // some code
    </>
  );
}

In that case, the ProfilePopover component will take care of everything and display the popover when we hover over its children. The ProfilePopover component itself includes at least four reusable components — Tooltip, Avatar, Text, and Icon.

Let’s hypothesize that the money saved from reusing a component instead of writing it anew each time is equal to the number of times that component is reused minus one (for the first time it was created) multiplied by the cost of its development (time spent on development multiplied by the monetary value of that time).

Money Saved = (Number of Uses − 1) × (Development Time × Cost Per Time Unit);

I would also like to add that reusing functions (for example, libraries like ) or your own is also relevant to the context of the article.

Let’s count the money

Let's imagine a situation (which I'm sure many of you have been in): you joined a project where the code for the editor had been written five times, yet not a single instance could be reused due to its structure. For your first task, you designed and implemented a reusable editor component. Over the next few years, the team reused it more than 40 times.

Considering that the first five editors were somehow different from each other (although they shouldn't have been) and were developed by different developers, meaning they weren't copied from one another, we can estimate that about 2-5 days were spent on their development. We'll take the average, which is 3,5 days. Of course, all these numbers are approximate and a product of our imagination, but let's calculate the cost of development in the first and second scenarios.

Let's count the numbers for New York. The average salary of a senior frontend developer in New York according to is $142,330 per year. To calculate the daily income, we would divide the annual salary by the number of working days in a year. In the United States, people typically work 5 days a week and have between 10 to 15 public holidays in a year. Therefore, the number of working days would be around 250 in a year.

Daily Salary (approximate) = 142330/250 ≈ 570 dollars per day

For the first scenario (where we write each editor separately) – the cost of the five already created editors was 570$ × 3.5 × 5 = 9975$. The cost of creating another forty such editors is frightening to even consider (but it is 79800$).

For the second scenario, we have a calculation of 1 × 3.5 × 570 = 1995$. Additionally, let's account for something we'll call a 'reusability surcharge.' We'll assume that we need to put extra effort into structuring the component to make it reusable and will add 30% for the complexity (although, in my opinion, the added complexity is likely only 0-10%):

1 × 3.5 × 570 × 1.3 = 2593$ . The cost of reuses is negligible.

In this case, we've discussed just one component. You can imagine how many components, both large and small, have either been reused or not in your own project, and what the cost implications of their reuse (or lack thereof) could be. And if the project has a thousand developers and thousands of components? Scary to even imagine.

It's important to put special emphasis on the fact that reusable components are generally of higher quality than those that are not reused. With frequent reuse, each component gets refined and improved. Additionally, if your project only has one editor component, then only that single component can break, as opposed to 40. This makes the maintenance of such code more cost-effective.

Beyond finances, reusability improves component quality, reduces maintenance, and simplifies development. Projects with integrated reusable components are agile and adaptable.

Your project has less technical debt and lower complexity, which also leads to a reduction in development costs.

Further Reading List

It was a very brief presentation of information, but If you want to delve into more complex aspects of this topic, I recommend that you read the following:

– This article focuses on estimating component reusability through the use of reusability metrics. It explores methods for estimating the reusability of black-box software components and proposes a metric for assessing this quality attribute. The authors conduct an experiment using a real-world component in a web application to illustrate the application of the proposed metrics.

– This article discusses the measurement of software component reusability using coupling and cohesion metrics. The authors investigate how these metrics can impact a component's potential for reuse. Coupling and cohesion metrics play a significant role in determining the quality and reusability of components.

– This article provides a critical survey of reusability aspects in component-based systems. It examines various factors affecting reusability and analyzes existing methods for assessing this characteristic. This offers an extensive overview of the research landscape in this domain.

– This article deals with the estimation of software reusability metrics using algorithms, models, and optimization techniques. It explores various methods and approaches for estimating reusability, including the use of mathematical models and optimization methods.

– This article explores the utility of object-oriented reusability metrics and estimation complexity. The authors study how these metrics can assist in assessing and improving component reusability. The article also touches on issues related to assessing code complexity.

Happy coding!