The Independent Variation Principle (IVP)
The structural definition:
Separate elements with different change driver assignments into distinct units; unify elements with the same change driver assignment within a single unit.
The Novel Contributions
What does IVP contribute that wasn't already present in Separation of Concerns, Information Hiding, SOLID or other software design principles? Here are the genuinely novel elements, organized as layers of a hierarchy of logic:
The Foundation
This layer recognizes the reality: The Partition Property grounded in Decisional Authority.
1. The Partition Property
Previous principles say "separate concerns" but don't specify how concerns relate to each other. IVP establishes that independent change drivers partition domain knowledge: they are disjoint (no overlap) and exhaustive (no gaps). This transforms vague advice into a mathematical structure. Every piece of knowledge belongs to exactly one driver; if it seems to belong to two, either the drivers aren't truly independent or the knowledge needs to be split.
2. Grounding in Decisional Authority
Earlier principles ground separation in technical criteria (information hiding), predicted change (encapsulate what varies), or vague "responsibilities" (SRP). IVP grounds separation in observable organizational reality: who has the authority to request changes? This shifts from speculation about future technical evolution to mapping existing decision structures—something that can be discovered through stakeholder interviews, not predicted through technical intuition.
3. The Relational Nature of Design Properties
IVP establishes that cohesion, coupling, responsibility, and change driver ownership are not intrinsic to code constructs but are relational—they emerge from the relationship between the construct and its context of use. A code element's membership in a change driver depends on context, not on inherent properties. This resolves persistent confusion in software design by anchoring relational properties in concrete, context-specific reality.
The Logic
This layer provides the rules: The Biconditional, the 1/n Purity scale, and the focus on Causal relationships over structural ones.
4. The Biconditional (IVP-1 + IVP-2)
Most principles focus on separation: "don't put different things together." IVP adds the equally important unification directive: "do put same things together." The biconditional—elements share a module if and only if they share change drivers—is stronger than either directive alone. It prohibits both over-separation (scattered concerns) and under-separation (mixed concerns).
5. Causal vs. Structural Cohesion
Traditional cohesion metrics are structural: do these elements access the same data? Call the same functions? IVP introduces causal cohesion: do these elements change for the same reason? Two elements with identical structural properties may have completely different causal relationships. This distinction is invisible to static analysis but fundamental to maintainability.
6. The Discrete Nature of Purity
IVP reveals that cohesion isn't continuous. A module with one change driver has purity 1; with two drivers, purity drops to 1/2; with three, to 1/3. Even "small" contamination (1% foreign knowledge) halves structural purity. This discreteness explains why architectural debt compounds: the first violation is disproportionately costly.
7. Transitive Coupling as Knowledge Gap
IVP reveals that problematic transitive coupling (A→B→C where changes to C propagate through B to A) reflects incomplete knowledge formalization. Element B mixes "knowledge A depends on" with "knowledge about C's implementation," creating multiple change drivers where there should be one. Transitive coupling is not merely a structural problem but a knowledge completeness problem.
The Action
The function of this layer is the construction: Deriving elements from knowledge and distinguishing necessary from accidental impurity.
8. Necessary vs. Accidental Impurity
IVP doesn't require all modules to have exactly one change driver. Adapters, bridges, and coordinators legitimately serve multiple drivers. The question is whether each driver is necessary for the module's purpose. This distinction—between modules that are impure by necessity and those that are impure by accident—resolves apparent counterexamples to single-responsibility thinking.
9. Derivation of Elements from Knowledge
IVP provides a principled answer to "what elements should exist?" Elements are not invented arbitrarily; they are derived from the partition structure of domain knowledge. For each change driver's knowledge partition, create elements that embody all knowledge in that partition. This grounds software structure in domain structure.
The Evaluation
The function of this layer is the optimization: The Objective Function. Prioritizing debt and measuring knowledge hygiene.
10. The Six Dimensions for Prioritization
IVP provides a framework for deciding which separations matter most: frequency, magnitude, predictability, control, scope, and authority distance. Not all IVP violations are equally urgent. This transforms IVP from a binary judgment ("compliant or not") into a prioritized improvement roadmap.
11. The Knowledge Theorem
IVP establishes a formal connection between knowledge organization and architectural quality: cohesion measures how completely a module embodies its concern's knowledge; coupling measures how much foreign knowledge has leaked in. This makes "good architecture" a matter of knowledge hygiene rather than aesthetic preference.
The Result
This layer concludes with the grand unification: The convergence of all prior principles.
12. Cohesion Primacy
IVP establishes that coupling and cohesion are not independent variables to be optimized separately. Focus on cohesion—ensuring each module fully embodies its concern's knowledge—and minimal coupling follows automatically. When a module contains all and only the knowledge for its change driver, there is nothing foreign to couple to and nothing missing that would require reaching elsewhere. This inverts the traditional framing: don't ask "how do I reduce coupling?" but "how do I complete the knowledge?"
13. The Unification of Prior Principles
Perhaps most importantly, IVP shows that Information Hiding, SRP, OCP, ISP, DIP, Package Architecture Principles, DDD bounded contexts, GoF patterns, EIP patterns and more are all instantiations of a single underlying principle. They aren't independent guidelines to be balanced against each other; they're different perspectives on the same truth. This unification simplifies architectural reasoning: instead of juggling multiple principles, apply IVP and the others follow.
Summary: The 13 Novel Contributions
| Layer | # | Contribution |
|---|---|---|
| Foundation | 1 | The Partition Property |
| 2 | Grounding in Decisional Authority | |
| 3 | Relational Nature of Design Properties | |
| Logic | 4 | The Biconditional (IVP-1 + IVP-2) |
| 5 | Causal vs. Structural Cohesion | |
| 6 | The Discrete Nature of Purity (1/n) | |
| 7 | Transitive Coupling as Knowledge Gap | |
| Action | 8 | Necessary vs. Accidental Impurity |
| 9 | Derivation of Elements from Knowledge | |
| Evaluation | 10 | The Six Dimensions for Prioritization |
| 11 | The Knowledge Theorem | |
| Result | 12 | Cohesion Primacy |
| 13 | Unification of Prior Principles |
Learn More
This article applies the Independent Variation Principle framework from:
Loth, Y. (2025). The Independent Variation Principle. Zenodo.
https://doi.org/10.5281/zenodo.17677316
The IVP paper provides a unified framework for understanding why certain abstractions work and when to apply them.
Top comments (0)