Name several architecture smells and the structural metrics used to detect them, and explain the limits of managing architecture by such metrics.

## What an architecture smell is A **smell** is a structural pattern that *suggests* a problem without proving one — the architecture-level analogue of a code smell. Architecture smells operate on modules, components, services and their dependencies rather than on statements and functions, so their cost is systemic: they constrain how independently parts can be understood, built, tested, deployed and owned. ## A working catalogue - **Cyclic dependency** — A depends on B which (directly or transitively) depends on A. The cycle collapses into a single de facto unit: it must be understood together, often built and released together, and cannot be tested in isolation. Cycles between modules are the single most cited architecture smell. - **God / hub-like component** — one component with unusually high incoming *and* outgoing dependencies. Every change risks touching it; it becomes a merge bottleneck and a point of ownership contention. The classic instance is the `common`/`shared`/`utils` module that grows to depend on everything. - **Unstable dependency** — a component that many things depend on (so it should be stable) itself depends on a volatile component. Every churn in the volatile part propagates upward. This inverts the **Stable Dependencies Principle**: depend in the direction of stability. - **Scattered functionality / shotgun surgery** — one business concept implemented across many modules, so a single logical change requires coordinated edits everywhere. Usually a symptom of boundaries drawn along technical layers rather than domain capability. - **Ambiguous interface** — a component exposing one generic entry point (`handle(request)`, `execute(command)`) that hides many unrelated operations, so callers cannot tell what it offers and static analysis cannot see real dependencies. - **Implicit / hidden coupling** — components integrating through a shared database schema, shared mutable global state, or a shared file format, so the dependency exists but is invisible to dependency analysis. Especially dangerous because automated checks report a clean graph. - **Dense structure** — a dependency graph whose edge count approaches the fully-connected case; nothing can be reasoned about locally. - **Feature concentration** — one module implementing many unrelated capabilities, so it changes for many independent reasons (module-scale violation of the Single Responsibility Principle). ## Metrics used for detection **Structural (from the dependency graph):** - **Afferent coupling (Ca)** — number of external components depending *on* this one (incoming; responsibility). - **Efferent coupling (Ce)** — number of external components this one depends *on* (outgoing; dependence). - **Instability I = Ce / (Ca + Ce)**, in [0,1]. I = 0 is maximally stable (many depend on it, it depends on nothing); I = 1 is maximally unstable. The Stable Dependencies Principle: dependencies should point toward lower I. - **Abstractness A** = abstract types ÷ total types in the component, in [0,1]. - **Distance from the main sequence D = |A + I − 1|**. The main sequence is the line A + I = 1: stable components should be abstract (so they can be extended without modification), unstable ones concrete. Large D flags the two problem zones — the *zone of pain* (stable and concrete: everything depends on it and it cannot be extended without modifying it) and the *zone of uselessness* (abstract with nothing depending on it). - **Cycle count / size of the largest strongly connected component** in the module graph. - **Propagation cost** — the fraction of components reachable from an average component through transitive dependencies; a direct measure of how far a change can ripple. **Historical (from version control — often more predictive than structure alone):** - **Change coupling / logical coupling** — files or modules repeatedly committed together despite no static dependency. Strong evidence of a misplaced boundary or hidden coupling. - **Hotspot churn** — change frequency crossed with complexity, identifying where structural cost is actually being paid. - **Contributor spread** — many teams editing one component signals ownership ambiguity and predicts defects. ## The limits — why metrics do not decide 1. **Proxies, not truth.** High Ca is expected and healthy for a well-designed shared domain library; the metric cannot tell a good hub from a god component. Only context — what the component *is for*, and how often it changes — distinguishes them. 2. **Thresholds are conventional.** There is no universal cutoff for "too much coupling". Values are meaningful relatively (against this codebase's own distribution and its trend over time), not absolutely. 3. **Goodhart's law.** When a measure becomes a target, it ceases to be a good measure. Targeting instability produces pointless interfaces; targeting cycle counts produces artificial indirection layers that break the static cycle while keeping the conceptual one. The system scores better and is no easier to change. 4. **Blind spots.** Static analysis misses coupling through shared databases, message payload formats, reflection, dynamic dispatch, configuration, and runtime service discovery. A clean graph can coexist with a tangled system. 5. **They locate, they do not diagnose.** A metric says "look here"; whether the structure is wrong, and what the right structure would be, requires domain understanding of why the component changes. 6. **Cost of remediation is invisible to the metric.** A high-D component nobody touches that would take three months to split is not a priority; metrics carry no notion of principal or of change traffic unless deliberately crossed with history. ## How to use them well Track a small set as **trends with alerts on deterioration**, not as scores to optimise. Encode the few rules you genuinely mean — no cycles between these modules, this module may not depend on that one — as build-failing checks (fitness functions), because a rule enforced at commit time prevents erosion far more reliably than a dashboard reviewed quarterly. Cross structural metrics with change history so attention lands where interest is actually paid, and always let a human decide what the target structure should be.