# Reusability

**In short:** Reusability is how well something you built, such as code or a design, can serve in more than one system. You can reuse by copying or by depending on shared code. Each way has costs and risks.

## Explanation

ISO 25010 is a standard quality model (see ISO/IEC 25010 Product Quality Model). It lists reusability under maintainability. The term means the degree to which a product can be an asset in more than one system, or in building other assets.

**Why people want it.** Starting from scratch can cost more time and effort than reusing existing high-quality code. In 1968, McIlroy pointed out that software had no components industry, unlike hardware. He saw no manufacturers or catalogues of standard parts. He wanted standard catalogues of routines.

**Two ways to reuse.**
- *Copying* places the original code into a new repository. It is quick. But the copy is harder to maintain and update.
- *Depending* leaves the external code unmodified. A package manager pulls it in.

**Risks.**
- Widespread copying can spread vulnerable code. Edits that differ between copies can cause unpredictable behavior.
- Dependencies carry risks too if nobody manages them. This is a supply-chain concern: you rely on code you did not write.
- An asset not designed for reuse, or not proven fit for purpose, can cause quality and safety problems.

**What makes reuse feasible.** Good interfaces. McIlroy expected a components industry to settle on a few standard interface types. Package repositories later grew from thousands to millions of components in the 2010s. Before that, software lacked interfaces good enough to make reuse feasible.

## Example

A team needs the same date-formatting logic in three products. In the first option, it copies the code into each product. A bug fix then has to be repeated three times, and one copy may be missed. In the second option, it publishes the logic as a shared package that all three products pull in. Now there is one place to fix bugs. But the team must also manage that dependency so it does not become a risk.

## Trade-offs

Copying is fast, but it makes later maintenance and updates harder and can spread flaws. Depending on shared code avoids duplicates, but it introduces dependency risks that need active management. Reusing code that was not designed for reuse can hurt quality and safety. Reuse still saves effort compared with building from scratch, so the choice depends on the case.



## Checks

- The document states whether each reused asset is copied or pulled in as a dependency.
- External dependencies have a documented way to manage their risks.
- Reused assets are checked as fit for purpose, or designed for reuse.
- Copied code has a documented plan for maintenance and updates.

## Related

- [Maintainability](https://arc.fuet.ch/concepts/quality-attributes/maintainability.md)
- [ISO/IEC 25010 Product Quality Model](https://arc.fuet.ch/concepts/quality-attributes/iso-iec-25010-quality-model.md)
- [Modularity](https://arc.fuet.ch/concepts/principles/modularity.md)
- [Technical Debt](https://arc.fuet.ch/concepts/evaluation/technical-debt.md)
- [Coupling and Cohesion](https://arc.fuet.ch/concepts/principles/coupling-and-cohesion.md)
- [Modifiability](https://arc.fuet.ch/concepts/quality-attributes/modifiability.md)
- [UML Interface](https://arc.fuet.ch/concepts/modeling-uml/uml-interface.md)
- [IT Component Catalogue](https://arc.fuet.ch/concepts/enterprise-architecture/it-component-catalogue.md)

## Sources

- [Maintainability](https://iso25000.com/index.php/en/iso-25000-standards/iso-25010/57-maintainability) — iso25000.com, accessed 2026-11-08
- [Beyond Dependencies: The Role of Copy-Based Reuse in Open Source Software Development](https://arxiv.org/html/2409.04830v1) — arxiv.org, accessed 2026-11-09
- [](https://mcilroy.cs.dartmouth.edu/components.txt) — mcilroy.cs.dartmouth.edu, accessed 2026-11-09
- [On the Future of Software Reusein the Era of AI Native Software Engineering](https://arxiv.org/html/2508.19834) — arxiv.org, accessed 2026-11-09