Distinguish architectural erosion from architectural drift, explain how a system becomes a "big ball of mud", and describe concrete mechanisms for preventing both.

## The two decay modes Dewayne Perry and Alexander Wolf's 1992 paper *Foundations for the Study of Software Architecture* introduced the distinction that is still the standard vocabulary. **Architectural erosion** — changes that **violate** the intended architecture. Someone imports across a forbidden boundary, a presentation component queries the database directly, one module reaches into another's internals instead of using its published interface, a supposedly asynchronous integration becomes a synchronous call "just this once". There is a rule, and it is broken. **Architectural drift** — changes made in **insensitivity** to the architecture. No stated rule is broken; the additions simply were not informed by the design intent. Symptoms: three caching approaches, four HTTP clients, two competing validation styles, a new capability lodged in whichever module was convenient, boundaries that no longer reflect the domain because the domain moved and the boundaries did not. The loss is of **conceptual integrity** — Fred Brooks' term for a system behaving as though designed by one mind. Why the distinction is practical: **erosion is mechanically detectable** — it is a rule violation, and rules can be encoded in automated checks. **Drift usually is not**, because nothing is technically wrong with any individual change; only the aggregate is incoherent. Drift is therefore caught by human review, architecture-description upkeep, and periodic structural assessment, not by CI alone. Teams that install dependency checks and declare victory have addressed only half the problem. ## The big ball of mud Brian Foote and Joseph Yoder (1997) named the most common architecture in practice: a haphazardly structured, sprawling, sloppy, spaghetti-code jungle — information promiscuously shared, near-global data access, and no discernible structure. Their key contribution was to explain it not as incompetence but as the predictable result of real forces: - **Time and cost pressure** — structure is invisible to customers, so it is the first thing cut. - **Experience and skill** — teams cannot build a structure they cannot yet see. - **Turnover** — design intent lives in people; when they leave and it was never written down, later changes cannot be sensitive to it. - **Piecemeal growth** — many locally reasonable changes summing to a globally unreasonable structure. - **Throwaway code that survives** — the prototype ships, then accretes features for a decade. - **Success** — mud is often what a system that *survived* long enough to matter looks like. A ball of mud is genuinely locally optimal for a while: anyone can change anything quickly. The cost arrives later as unbounded change impact — every modification can affect anything, so nothing can be reasoned about locally, estimates become unreliable, and change failure rate rises. ## Detection signals - Cyclic dependencies between modules or packages. - Change coupling: files with no logical relationship repeatedly committed together. - Shotgun surgery — one conceptual change touching many modules. - Rising lead time for changes of comparable size; widening estimate variance. - Onboarding time increasing over releases. - Nobody able to draw the system's structure — and no two drawings agreeing. - "Everything depends on the shared/common/util module." ## Prevention and recovery mechanisms **Make the architecture explicit.** An undocumented architecture cannot be violated knowingly or respected reliably. Lightweight diagrams plus **architecture decision records** capturing the decision, its context, alternatives and consequences give later engineers what they need to stay sensitive to intent — the main antidote to drift under turnover. **Automate the rules — fitness functions.** From *Building Evolutionary Architectures* (Ford, Parsons, Kua): an architectural fitness function is any automated test of an architectural characteristic. Concretely: dependency-rule tests that fail the build when a forbidden import appears, cycle detection, layer checks, module-boundary verification, performance and startup budgets, security policy checks. Run them in CI on every change so erosion is caught at the commit that causes it rather than at an annual review. This converts architecture from documentation into an executable constraint. **Small, verified structure changes.** Prefer continuous restructuring over accumulate-then-rewrite. Big-bang rewrites are the classic response and usually the wrong one: they freeze feature delivery, carry unknown behavioural-parity risk, and are exposed to the second-system effect (over-engineering the replacement). The **strangler fig** pattern — route traffic incrementally to new components while the old system shrinks — keeps value flowing and risk incremental. **Adjust boundaries as the domain is learned.** Much drift is boundaries that were reasonable initially and are now wrong. Treat module boundaries as revisable, informed by change-coupling data and domain analysis rather than by the original org chart. **Sacrificial architecture.** If you knowingly build something to be replaced (to learn the domain fast), say so explicitly, keep it isolated behind interfaces, and plan its replacement — converting inevitable decay into a deliberate, prudent decision instead of an accident. **Guard the seams organisationally.** Because team structure shapes system structure (Conway's law), boundaries that cut across team lines erode fastest. Align ownership with the boundaries you want preserved, and make each boundary's public interface someone's explicit responsibility.