The Independent Variation Principle

For fifty years, software design principles have been debated as matters of taste — “high cohesion, low coupling” sounds plausible but no one could prove where the boundaries should actually go. Two architects could look at the same system and draw different boxes, with no criterion to decide who was right.

This article presents a visual proof that the question is not a matter of taste.

Every software system is a graph: elements are vertices, dependencies are edges, and every element responds to one or more change-drivers — external forcing conditions like tax regulations, payment rules, UI layouts, or security policies.
When you draw this graph and group vertices by their change-driver sets, the correct module boundaries are not a design choice. They are a mathematical consequence of minimizing change propagation cost.

The Independent Variation Principle (IVP) states the result: elements with the same change-drivers belong together; elements with different change-drivers
belong apart. The proof is a counting argument on the incidence graph — entirely graph-theoretic, requiring no economics or calibration.

This article requires no mathematics beyond counting and no programming knowledge beyond the concept of a dependency. Its thesis: once change-drivers are identified, where module boundaries should go is not a matter of taste but a structural consequence you can read off the graph.