Why Code Reuse Often Fails to Improve Efficiency in System Design

In system design and coding, the term "reuse" is frequently heard, and many try to design technologies, business processes, and organizational structures with reuse as the primary goal.

Abstract a class, function, or UI component for different scenarios.

Abstract a micro‑service, making it as fine‑grained as possible for flexible composition.

Abstract a business‑mid‑platform to consolidate basic functions for company‑wide use.

Abstract a functional silo (backend, frontend, QA, finance) in the organization for multiple products.

Reuse a previously designed feature when a new performance requirement resembles an existing one.

Why do we like reuse?

Main purpose: If a function already exists, why reinvent it? Using existing code reduces effort and increases personal productivity.

Education: Engineers are taught the DRY principle; the classic book "Design Patterns" is subtitled "Reusable Object‑Oriented Software".

Programming habit: In OOP languages, inheritance is commonly used, and its goal is reuse.

What is the reasoning that reuse improves efficiency?

If we wrote every line of a system ourselves, we would need a huge amount of code.

Reusing previously written code lets us write less.

The more code we can reuse, the less new code we need to write.

Writing less code means the system can be completed earlier.

This reasoning contains two fallacies:

All code (features) takes the same amount of time to write.

Writing code is the dominant work in delivering a system.

If a component depends on many other reusable modules, developers must understand each module’s interface, often beyond what documentation provides; mismatched interfaces force trade‑offs between using the module and meeting schedule constraints.

Moreover, there is no standard for abstracting a common business module; the module owner often becomes an outsourced function, reducing efficiency.

Maintenance, not coding, consumes the majority of time in production systems. A highly reused module that many other modules depend on is far harder to maintain than a simpler, less‑dependent one.

Should we write our own versions of frameworks or algorithm libraries? No. We routinely use languages (Java, Go), frameworks, and libraries that are widely accepted standards, not custom‑built for a single business.

Is making every component as generic as possible (e.g., many CRUD micro‑services) the right way to improve productivity? Not necessarily. Blindly pursuing reuse can lead to “organ‑transplant” style integration, causing rejection reactions, slower development, and instability. Common pitfalls include:

Tables with hundreds of fields where it’s unclear which fields apply to which scenario.

Designing systems around business nouns, resulting in fragmented mid‑platforms (order platform, e‑commerce platform) and constant inter‑departmental tug‑of‑war.

Proliferation of tiny micro‑services managed by a complex orchestration layer (gateway) with custom DSLs, leading to difficult deployments and a single point of failure.

Good design should follow the advice from "Hints for Computer System Design": use a good idea again instead of over‑generalizing; a specialized implementation can be far more effective.

What are the standards for evaluating a good system design?

Autonomy : Measure how much a module is affected by others; stable interfaces can be evaluated with AutonomyMetrics[1].

Consistency : Ensure a module is used in a single place; avoid premature or excessive abstraction, measurable with ConsistencyMetrics[2].

When deciding whether to extract a shared module from multiple business components, consider whether the shared logic needs to change together; if not, do not abstract it.

When torn between consistency and autonomy, prioritize autonomy.

Summary

In most cases, core system complexity does not decrease—it merely shifts. Writing code in parallel does not automatically speed up delivery; division of labor is necessary but not sufficient. Avoid arbitrary generalization for reuse; use ConsistencyMetrics[2] to judge abstraction reasonableness. Do not reuse modules indiscriminately—measure autonomy with AutonomyMetrics[1] and ensure consensus and standards before reusing.

Related links:

AutonomyMetrics

ConsistencyMetrics