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: . And so, I told him: how to communicate the significance of this to people on the business side 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, Are there metrics for this? Formulas?". Let’s dive deeper. "Is there a way to quantify how much a company actually saves if the developers 'do it right'? 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 , but the concept can be applied to any kind of development. React.js framework 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 — , , , etc. This is absolutely the right approach, but many projects go beyond this to have , 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. various UI libraries Storybook here buttons accordions avatar components more complex 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 component will take care of everything and display the popover when we hover over its children. The component itself includes at least four reusable components — , , , and . ProfilePopover ProfilePopover Tooltip Avatar Text Icon Let’s hypothesize that the money saved from reusing a component instead of writing it anew each time is equal to (for the first time it was created) the number of times that component is reused minus one 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. lodash 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. Glassdoor Daily Salary (approximate) = 142330/250 ≈ 570 dollars per day (where we write each editor separately) – the cost of the five already created editors was . The cost of creating another forty such editors is frightening to even consider (but it is ). For the first scenario 570$ × 3.5 × 5 = 9975$ 79800$ , we have a calculation of . 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%): For the second scenario 1 × 3.5 × 570 = 1995$ . The cost of reuses is negligible. 1 × 3.5 × 570 × 1.3 = 2593$ 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 , which also leads to a reduction in development costs. less technical debt and lower complexity 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: – Estimation of Component Reusability through Reusability Metrics 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. – Measuring Software Component Reusability by Coupling and Cohesion 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. – A Critical Survey of Reusability Aspects for Component-Based Systems 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. – Software reusability metrics estimation: Algorithms, models and optimization techniques 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. – Utility of an Object Oriented Reusability Metrics and Estimation Complexity 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!
