How do the Stable Dependencies Principle and the Stable Abstractions Principle combine into the "main sequence", and what do the Zone of Pain and Zone of Uselessness mean?

### Why SDP needs a partner SDP tells you which way arrows point but says nothing about *what is inside* a component. Follow SDP alone and you converge on a few maximally stable components at the bottom of the graph — extremely hard to change, by construction. If those components are packed with concrete, volatile business logic, you have built a system whose most change-resistant parts are exactly the ones the business wants to change. That is rigidity. ### Stable Abstractions Principle (SAP) > **SAP: a component should be as abstract as it is stable.** An **abstract type** is one that cannot be instantiated on its own and carries no (or minimal) implementation — an interface, an abstract class, a protocol, a trait, a pure signature. Depending on an abstract type couples you to a *shape*, not to a decision. The reason SAP works is the **Open/Closed Principle** — software should be open for extension, closed for modification. An abstract, stable component can gain new behaviour by someone writing a new implementation *elsewhere*, with no edit to the stable component and therefore no blast radius. So high stability stops being a liability. **Abstractness metric:** ``` A = (number of abstract types in the component) / (total number of types in the component) ``` A = 0: entirely concrete. A = 1: nothing but abstractions. ### The graph Put I (instability, 0 → 1) on the x-axis and A (abstractness, 0 → 1) on the y-axis. Two corners are obviously bad and two are obviously fine: - **(I=0, A=1)** — maximally stable and maximally abstract. Everyone depends on it; it is pure interface. Ideal for a contract/port component. - **(I=1, A=0)** — maximally unstable and fully concrete. Nobody depends on it; it is all detail. Ideal for a UI screen, a `main`, a job script. The **main sequence** is the straight line joining those two good corners: ``` A + I = 1 ``` Components should sit *on or near* it. Distance from the line: ``` D = | A + I − 1 | 0 ≤ D ≤ 1, lower is better ``` (Some texts use a signed normalized form D′ = (A + I − 1); the absolute version is the common one.) ### The two bad corners **Zone of Pain — near (I=0, A=0): stable and concrete.** Many components depend on it, and it is rigid — you cannot extend it, only edit it, and every edit ripples across all dependents. The archetype is a big shared "utils"/"common" library of concrete helpers that the whole system imports, or a concrete database schema that everything is written against. Every change is expensive; teams work around it, fork it, or add flags. *But the zone has legitimate inhabitants.* A component that is concrete and stable but **genuinely never changes** is harmless — the pain only materializes when change arrives. Classic examples: a mature string/date library, a stable third-party database driver, a frozen protocol codec. The heuristic to apply is volatility, not just the coordinates. **Zone of Uselessness — near (I=1, A=1): abstract and unstable.** Full of abstract types that nobody depends on. These are leftover interfaces, speculative extension points nobody implemented, abstractions written "in case we swap X" for a swap that never came. They are dead weight: cognitive load, build time, and false signals of flexibility. The fix is usually deletion. ### Reading the picture in practice - Compute A, I and D for every component; sort by D descending. - High D near the origin → candidate rigidity. Ask: does this actually change? If yes, extract interfaces (raise A) or split out the volatile concrete parts into higher-I components. - High D near (1,1) → candidate dead abstraction. Ask: who implements this, who calls it? If nobody, delete. - Track D over time rather than as an absolute pass/fail; a component drifting away from the line is more interesting than one that has always sat slightly off it. ### Honest limitations - **A is crude.** Counting types treats a one-method interface and a fifty-method god interface identically, and languages differ in what counts as abstract (Kotlin/Java interfaces, Go implicit interfaces, Python duck typing with no declared abstract type at all). In a duck-typed language A may be near-meaningless without discipline like explicit protocol/ABC declarations. - **The main sequence is a heuristic, not physics.** There is no theorem that A + I = 1 is optimal; it is an empirically useful line drawn between two agreed-good corners. - **Granularity again.** How you carve components moves every point on the chart. - **Do not target D in CI.** People raise A by adding pointless interfaces — which is precisely how you manufacture the Zone of Uselessness while improving the score.