• Home
  • BVSSH
  • C4E
  • Playbooks
  • Frameworks
  • Good Reads
Search

What are you looking for?

Standard : Duplicated Components

Description

Duplicated Components measures the number or proportion of components—such as services, infrastructure modules, data pipelines, or UI widgets—that are implemented more than once across systems or teams when reuse would be feasible.

High duplication leads to increased maintenance burden, divergence in behaviour, and hidden coordination costs across teams.

How to Use

What to Measure

  • Count of components (e.g. functions, modules, services) with significant logic, structure, or config overlap.
  • Ratio of duplicated components versus total similar component types (e.g. buttons, APIs, pipelines).
  • Volume of duplicate data transformations or ingestion logic.

Formula

Duplicated Component Ratio (%) = (Duplicated Components / Total Components) × 100

Instrumentation Tips

  • Use static analysis tools (e.g. SonarQube, DeepSource) for code duplication metrics.
  • Implement component registries or catalogs for UI, API, or data products.
  • Run periodic audits of infra modules, Terraform patterns, or platform services.
  • Establish naming conventions and tagging to identify clones or forks.

Why It Matters

  • Reduces waste: Avoids solving the same problem multiple times.
  • Lowers maintenance cost: Fewer moving parts and less divergence.
  • Improves consistency: Reused components reduce defects and user confusion.
  • Enables platform thinking: Encourages shared services and scalable design.

Best Practices

  • Create internal libraries or registries for shared components.
  • Promote platform enablement teams to build and maintain reusable primitives.
  • Use discovery tooling to help engineers find existing solutions.
  • Include reuse goals in technical design reviews and spikes.
  • Review duplication metrics in architectural communities or guilds.

Common Pitfalls

  • Teams build similar functionality in isolation due to lack of visibility or incentives.
  • Overzealous standardisation leads to brittle “one-size-fits-all” components.
  • No shared ownership for reusable components results in neglect.
  • Duplication is tolerated because short-term delivery wins trump long-term sustainability.

Signals of Success

  • Duplicate logic is routinely identified and consolidated.
  • Reuse is incentivised and visible in engineering KPIs.
  • Internal registries are well-used and contribute to speed and consistency.
  • Tech debt audits highlight reduced proliferation of similar components.

Related Measures

  • [[Unused Feature Ratio]]
  • [[Engineering Rework Due to Poor Upstream Clarity]]
  • [[Platform Adoption Coverage]]
  • [[Manual Intervention Rate in Pipelines]]
  • [[Time to Onboard New Engineers]]

Technical debt is like junk food - easy now, painful later.

Awesome Blogs
  • LinkedIn Engineering
  • Github Engineering
  • Uber Engineering
  • Code as Craft
  • Medium.engineering