Once a program structure has been developed using functional decomposition, effective modularity can be achieved by manipulating it according to the following heuristics. 1. EVALUATE THE FIRST ITERATION OF THE PROGRAM STRUCTURE TO REDUCE COUPLING AND IMPROVE COHESION. Once developed, modules may be EXPLODED or IMPLODED. EXPLODE — a module performing several tasks is split into more, single-purpose modules. Do this when cohesion is low. IMPLODE — several modules whose processing occurs in a fixed sequence and whose data is shared are combined. Do this when the split created coupling without buying independence. The guiding rule: STRIVE FOR FUNCTIONAL INDEPENDENCE. Modules with high cohesion and low coupling should be the goal. 2. ATTEMPT TO MINIMISE STRUCTURES WITH HIGH FAN-OUT; STRIVE FOR FAN-IN AS DEPTH INCREASES. FAN-OUT the number of modules directly controlled by a module. High fan-out (say > 7) suggests the module is a dispatcher doing too much coordination — the "God controller". FAN-IN the number of modules that directly call a module. High fan-in low in the hierarchy is GOOD: it means a genuinely reusable utility. The healthy shape is therefore not a flat wide tree nor a narrow deep one, but an OVAL — narrow at the top, wide in the middle, converging on shared services at the bottom. 3. KEEP THE SCOPE OF EFFECT OF A MODULE WITHIN THE SCOPE OF CONTROL OF THAT MODULE. SCOPE OF CONTROL of module m = m itself plus all modules subordinate to it. SCOPE OF EFFECT of a decision made in m = all modules affected by that decision. THE RULE: if a decision made in m affects a module NOT subordinate to m, the structure is wrong — because the affected module cannot be reasoned about locally. Either move the decision up, or restructure. 4. EVALUATE MODULE INTERFACES TO REDUCE COMPLEXITY AND REDUNDANCY AND IMPROVE CONSISTENCY. A complex interface is a prime source of errors. It should communicate simple information and be consistent with the module's function — an interface that passes data unrelated to what the module does signals a design error. 5. DEFINE MODULES WHOSE FUNCTION IS PREDICTABLE, BUT AVOID MODULES THAT ARE OVERLY RESTRICTIVE. PREDICTABLE (a "black box"): the same input always yields the same result, with no side effects, and the caller need not know the internals. A module that maintains hidden internal state across calls is unpredictable and untrustworthy. BUT: a module restricted to a single narrow case (a table size hard-coded, a currency assumed) forces the caller to work around it. Parameterise what genuinely varies. 6. STRIVE FOR CONTROLLED ENTRY MODULES, AVOIDING "PATHOLOGICAL CONNECTIONS". Software should be entered at its top — ONE entry, ONE exit. A pathological connection is a branch or reference into the MIDDLE of a module. It makes the module impossible to reason about and impossible to change safely. (Content coupling, in the coupling ladder.) 7. PACKAGE SOFTWARE BASED ON DESIGN CONSTRAINTS AND PORTABILITY REQUIREMENTS. Packaging = the assembly of software into physical modules. Where memory is constrained, or platform portability matters, package so that the constrained or platform-specific parts are isolated. Requirements may dictate that a program overlay itself, or that modules be separately loadable.

A FIRST-CUT DESIGN for the licence system's reporting feature: ReportController ├── fetchApplications() ├── fetchOfficers() ├── fetchFees() ├── computeTotals() ├── formatAsPdf() ├── formatAsExcel() ├── emailReport() ├── logReportRun() └── updateDashboardCache() DIAGNOSIS, heuristic by heuristic: H2 FAN-OUT = 9. Well above the ~7 guideline. This is a dispatcher, and every new report format or delivery channel widens it further. H1 COHESION of ReportController is TEMPORAL at best — these nine things are related only by "happen during a report run". Data access, computation, formatting, delivery and caching are four different concerns. H4 INTERFACE COMPLEXITY: computeTotals() must receive applications, officers AND fees — a large parameter list signalling that the data-gathering concern has leaked into the computation concern. H3 SCOPE OF EFFECT: updateDashboardCache() means a decision made inside the report run affects the dashboard, which is not subordinate to ReportController. A report should not be able to break a dashboard. RESTRUCTURED, applying EXPLODE and then IMPLODE: ReportService (fan-out 3) ├── ReportDataGateway ← implodes the three │ fetchReportData(spec) fetch* modules; they │ ran in fixed sequence │ and shared data (H1) ├── ReportCalculator ← pure function: │ totals(data) → Totals predictable, no side │ effects (H5) └── ReportRenderer ← explodes into a strategy render(totals, format) interface; PdfRenderer and ExcelRenderer are siblings with HIGH FAN-IN from any caller (H2) Delivery and cache-invalidation move OUT, triggered by a ReportGenerated event — so a report no longer reaches into the dashboard (H3), and adding an SMS channel touches nothing in ReportService. MEASURED IMPROVEMENT: fan-out 9 → 3 cohesion temporal → functional (each new module has one task) coupling stamp/control → data + message new output format edit ReportController → add one class testability needs a DB, a mailer and a cache → ReportCalculator is a pure function testable with no infrastructure at all THAT LAST LINE IS THE PRIZE. The heuristics are not aesthetics; the restructured design has a piece you can unit test in microseconds, and the original did not.

Heuristics are qualitative. Two measures make them checkable. CYCLOMATIC COMPLEXITY (McCabe) — the number of linearly independent paths through a module. V(G) = E − N + 2P E = edges in the control-flow graph N = nodes P = connected components (1 for a single module) Equivalently, for a single module: V(G) = (number of binary decision points) + 1 EXAMPLE — a fee validator: if (amount <= 0) return ERR_NEGATIVE; if (amount > MAX_FEE) return ERR_TOO_LARGE; if (district == null) return ERR_NO_DISTRICT; if (isHoliday(date) && !allowHolidayPayment) return ERR_HOLIDAY; return OK; decision points: 3 simple ifs + 1 if with && (which is 2 decisions) = 5 V(G) = 5 + 1 = 6 → 6 independent paths, so a minimum of 6 test cases for full path coverage INTERPRETATION (the widely used bands): 1–10 simple, low risk 11–20 moderate complexity, moderate risk 21–50 complex, high risk > 50 untestable, very high risk V(G) is ALSO A LOWER BOUND ON TEST CASES for basis-path coverage, which is what makes it useful rather than merely descriptive. STRUCTURAL COMPLEXITY / COUPLING METRIC: Structural complexity of module i: S(i) = f_out(i)² → complexity grows as the SQUARE of fan-out, which is the quantitative justification for heuristic 2. Data complexity: D(i) = v(i) / (f_out(i) + 1) where v(i) is the number of input and output variables passed to and from module i. System complexity: C(i) = S(i) + D(i) As each of these increases, the overall architectural complexity increases, leading to greater integration and testing effort. APPLIED TO THE EXAMPLE ABOVE: before: S = 9² = 81 after: S = 3² = 9 A 9-fold reduction in structural complexity from one restructuring — and that is exactly what heuristic 2 is claiming when it says "minimise fan-out". MORPHOLOGY measures for a program structure with n nodes and a arcs: size = n + a depth = longest path root → leaf width = maximum number of nodes at any one level arc-to-node ratio r = a / n — a measure of coupling A high r means many connections per module, i.e. high coupling; comparing r across candidate designs is a cheap way to choose between them.