software-design-complexity

To evaluate deep vs shallow modules during a software architecture review, apply the depth ratio metric to assess whether a module's interface complexity is justified by its hidden implementation functionality, then decide whether to merge or split module boundaries.

Information leakage in software design occurs when implementation details escape through a module's interface. Detect it during refactoring audits by analyzing module boundaries to identify where internal complexities are exposed to external callers, violating information hiding principles.

Reduce software complexity when refactoring by auditing module boundaries to identify leakage and depth issues, then consolidating responsibilities. Apply strategic design choices that prioritize deep modules and strict information hiding over tactical programming adjustments.

The difference between strategy-based and tactical programming is that strategic design focuses on minimizing complexity through deep modules and information hiding, while tactical programming addresses immediate problems without considering long-term architectural complexity, often increasing technical debt.

Use a depth-first design approach for software architecture during architecture reviews, refactoring sessions, and design discussions. It is applied when you need to identify complexity hotspots, enforce module depth criteria, and prevent information leakage across system boundaries.