Skip to content
Software Architecture Guide

Reusability

Explanation

Section titled “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

Section titled “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

Section titled “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

Section titled “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.
Section titled “Related”

Sources

Section titled “Sources”