Cohesion & Coupling
The five kinds of coupling that actually differ in cost, why cohesion is the other half of the same question, and how fan-in, fan-out and cycles show up in a real dependency graph.
A module is cohesive when its parts change for the same reason. Cohesion and coupling are one question asked twice: what belongs together, and what may know about what.
Data, control, temporal, shared-state and implementation coupling are not degrees of one thing. They differ by an order of magnitude in cost, which is why the taxonomy is worth having.
When calls must happen in an order the type system does not know about, the ordering lives in someone's head — and heads leave.
Two modules connected through a mutable structure neither of them owns. The most expensive kind, because there is no list of who writes to it.
How many modules depend on this one, and how many does it depend on. Both are signals about where change lands — and neither, on its own, is a verdict.
A cycle turns three modules into one. You cannot reason about, test, initialize, extract or delete any of them without the others.
Who depends on me, and what do I depend on. A useful pair of questions, a widely published pair of metrics, and a gap between the two that is worth being honest about.