The Pitfalls of Over‑Reuse in System Design: Autonomy, Consistency, and Practical Guidelines

In system design and coding, the term "reuse" is frequently heard, and many architects aim to design technologies, business, and organizational structures with reuse in mind. Typical examples include abstracting classes, functions, UI components, micro‑services, business middle‑platforms, functional teams, and reusing similar product features.

Why do we like reuse?

Primary goal: If a function already exists, why reinvent it? Using existing code reduces effort and boosts personal productivity.

Education: Engineers are taught the DRY principle; design‑pattern literature emphasizes reusable object‑oriented software.

Programming habit: In OOP, inheritance is often used for reuse.

Promotional note: Respond to the backend architect’s “clean architecture” message to receive a surprise gift.

Logical reasoning behind the efficiency claim of reuse

Writing all code for a system from scratch requires a large amount of code.

Reusing previously written code reduces the amount of new code.

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

Less code means the system can be completed earlier.

This reasoning contains two fallacies:

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

Assuming coding is the main work in building a system.

If a module 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 its release schedule.

Moreover, abstracting a public business module without clear standards often turns the module owner into an outsourced function, reducing efficiency.

Maintenance, not coding, consumes the majority of time in production systems. Debug‑deploy‑debug cycles become more complex when a module is heavily reused across many dependents.

Common pitfalls of forced reuse

Hundreds of fields in a single table (e.g., order table) with unclear applicability.

Designing systems around nouns, leading to business middle‑platforms that cause inter‑departmental friction.

Creating numerous tiny micro‑services and a centralized orchestration layer (gateway/DSL), resulting in complex releases and a single point of failure.

Good design should follow the advice from "Hints for Computer System Design": reuse a good idea rather than over‑generalizing it; a specialized implementation can be more effective.

Evaluation criteria for system design

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

Consistency : Measure whether the same module is used consistently across the codebase; over‑abstraction can be detected with ConsistencyMetrics[2].

When deciding whether to abstract a common business logic into a shared module, consider whether the logic needs to change together across multiple services; if not, avoid abstraction.

When torn between autonomy and consistency, prioritize autonomy.

Summary

Do not pursue reuse for its own sake; use ConsistencyMetrics[2] to judge whether abstraction is reasonable.

Do not reuse arbitrarily; prioritize autonomy using AutonomyMetrics[1]; ensure any reused module follows established consensus and standards.

Related links:

https://autonomy.design/Part1/AutonomyMetrics.html

https://autonomy.design/Part1/ConsistencyMetrics.html

Reference links:

https://zhuanlan.zhihu.com/p/356202989

https://udidahan.com/2009/06/07/the-fallacy-of-reuse/

https://zhuanlan.zhihu.com/p/138145081

https://zhuanlan.zhihu.com/p/410049005