How should software be modularized, and why that way? A new preprint answers both questions with a proof — and the answer is the Independent Variation Principle (IVP).
Elements with identical change-driver sets belong in the same module; elements with different change-driver sets belong in different modules.
A change-driver is an external condition — a regulation, a contract, a protocol specification — whose change forces governed elements to change. The how is the rule itself; the why is that this exact grouping, and no other, minimizes the cost of change. For fifty years that second question — why these boundaries rather than those — had only well-motivated opinion behind it. This paper turns the answer into a theorem.
The proof is a counting argument
Draw a bipartite incidence graph: elements on one side, change-drivers on the other, edges recording which drivers govern which elements. On that graph, two lemmas show that any modularization deviating from the IVP prescription pays a strictly higher cost — either by scattering same-driver elements across modules, or by mixing different-driver elements in the same module.
The Γ-equality partition — the one that groups elements by identical change-driver sets — is not one good option among several. It is the unique cost-minimizing modularization.
Why more than five decades of principles couldn't settle this
Information hiding, the SOLID and package rules, layered and hexagonal architectures, domain-driven boundaries — each distilled real experience into advice about where to draw module boundaries, and each is a heuristic. They share one structural limitation: none was derived from a cost objective, or any other clearly stated objective, so none can prove its boundaries are optimal rather than merely reasonable, and where two of them disagree there is no principled way to say which is right.
Some are also internally inconsistent. Martin's Common Closure and Reuse/Release principles, for instance, cannot both be satisfied under client-driven interface evolution — and the framework names no winner. The common root is the absence of a single objective to optimize against.
What the proof gives you
This paper supplies that objective and proves the consequence. Once the change-drivers are identified, the question "which elements change for the same reasons?" becomes the precise predicate Γ(e₁) = Γ(e₂) — grouping by the external conditions that govern an element, not by which changes happen to be probable or which have co-occurred in the commit history — and the optimal boundaries follow from it by counting. No competing rules to reconcile, no judgment, no taste, no appeal to accumulated experience.
Yannick Loth. The Independent Variation Principle: Deriving Optimal Module Boundaries from the Element–Change-Driver Graph. June 2026.
📄 Free preprint on Zenodo — DOI: 10.5281/zenodo.20794332