Under the Stable Dependencies Principle, does a component that is edited every day automatically count as unstable? Explain the difference between stability and volatility, and why it matters.

### Two different questions - **Stability (structural):** *How hard would it be to change this?* Determined by the dependency graph: many dependents (high Ca) and few dependencies (low Ce) → stable, I near 0. This is what SDP and the instability metric measure. - **Volatility (behavioural):** *How often does this actually change?* Determined by the domain: pricing rules change monthly, a UI is redesigned quarterly, a physics constant never changes. Nothing in the dependency graph tells you this — it comes from requirements, roadmap and version-control history. SDP is stated in terms of stability, but its *motivation* is volatility. The reason you want arrows pointing toward stable components is so that churn does not propagate. If a hard-to-change component never changes, its hardness costs nothing. ### The four quadrants | | Low volatility (rarely changes) | High volatility (changes often) | |---|---|---| | **Stable** (many dependents, I ≈ 0) | Ideal foundation — a maturing core domain model, a frozen protocol library. Hard to change, but you never need to. | **The danger zone.** Every edit ripples across the whole system: mass rebuilds, mass retests, coordinated releases, angry consumers. | | **Unstable** (no dependents, I ≈ 1) | Slightly wasteful — a leaf component that nobody depends on and that nobody touches. Often dead code. | Ideal for churn — UI screens, feature modules, `main`/composition roots, experiments. Change them freely; nobody notices. | SDP's practical goal is to keep the system out of the top-right cell by pushing volatile things into the bottom-right cell. ### How the danger cell gets built - A `common`/`utils`/`shared` library accretes business rules because it is convenient to import; everyone depends on it and it changes weekly. - A shared data model or generated-from-schema types package sits at the bottom of the graph and changes with every schema tweak. - A "core" service in a distributed system owns policies that the business revises constantly, and every other service calls it synchronously. Each one looks fine by I alone — low I is supposed to be good! — which is exactly why the metric must be read together with change history. ### The audit technique 1. Build the component dependency graph and compute I per component. 2. Pull change frequency per component from version control (commits, or better, distinct change-requests touching it, over 6–12 months). 3. Plot or table them together: **low I × high change frequency = top risk**. 4. For each hot spot, decide: - **Split it.** Extract the churning part into a new high-I component; leave the genuinely stable remainder behind. Usually the best fix for a bloated `common`. - **Invert it.** Turn the churning behaviour into an abstraction the stable component owns, with volatile implementations above it (DIP). - **Abstract it.** Raise abstractness so consumers depend on shapes, not decisions — churn behind the interface stops rippling (Stable Abstractions Principle). - **Reduce the churn.** Sometimes the requirements really did stabilize and the history is stale; check before restructuring. ### Edge cases - **Change frequency lies both ways.** A component may be quiet because it is *too painful* to change (frozen by fear), which is the Zone-of-Pain symptom, not health. And a burst of commits may be one refactor, not ongoing churn — look at distinct authors and distinct reasons. - **Additive change is cheaper than breaking change.** A stable component that only ever gains new optional API surface does not ripple the same way. Weight the history by whether changes broke consumers. - **Forecast, not just history.** Volatility is about the *future*; the roadmap can tell you a currently-quiet component is about to become the hottest thing in the codebase. Restructure before the churn, not after.