*Out of the Tar Pit* is a 2006 paper by Ben Moseley and Peter Marks that has become one of the most cited works on software complexity. Building on Brooks's *No Silver Bullet*, the authors argue that complexity is the single largest cause of failed software projects, and they go further than Brooks did in distinguishing the kinds of complexity software contains and what to do about each.
## The Central Claim
Moseley and Marks contend that complexity, not size or technology, is the dominant force that makes software hard to write, understand, modify, and maintain. They distinguish three sources:
- **Essential complexity**: Inherent in the problem domain. Cannot be eliminated, only managed
- **Accidental complexity**: Introduced by the tools, languages, and approaches we choose. Can be reduced or eliminated
- **Complexity caused by state**: A specific and dominant source of accidental complexity that they single out for special treatment
Their innovation over Brooks is the focus on **state and control flow** as the chief generators of accidental complexity in mainstream software, and on **declarative, relational, and functional** approaches as ways to systematically reduce them.
## The Three Causes of Complexity They Target
- **State**: Mutable variables and side effects make program behavior dependent on history. The number of possible system states grows combinatorially. Most bugs and most difficulty in reasoning come from state
- **Control**: Imperative ordering of operations forces the programmer to think about *how* a result is computed, not just *what* it should be. Concurrency multiplies this difficulty
- **Code volume**: Every line of code is something to read, test, maintain, and get wrong. Less code is generally less complexity, all else equal
## The Proposed Discipline
The paper proposes systematically classifying every piece of a system into one of four buckets, then choosing the appropriate tool for each:
- **Essential state**: Data that the user genuinely cares about. Should be expressed in a relational model and persisted explicitly
- **Essential logic**: Pure functions and constraints derived from the problem. Should be expressed declaratively whenever possible
- **Accidental state and control**: Caches, indexes, materialized views, optimizations. Should be treated as separable, ideally derivable, and labeled as accidental
- **Other**: Everything else (UI, infrastructure, glue) — minimize it
The authors propose **Functional Relational Programming (FRP)** as a hypothetical architecture combining functional programming for logic, the relational model for essential state, and explicit, labeled accidental state for performance — keeping the bulk of the program declarative and pure.
## Practical Influence
The paper has shaped thinking in several modern movements:
- **Functional programming adoption**: Languages like Clojure, Elm, F#, and Haskell are often justified in terms similar to those Moseley and Marks use
- **Immutable data structures**: A foundational pattern in modern frontend (Redux, React state immutability) and backend (event sourcing) design
- **Declarative configuration**: Tools like Terraform, Kubernetes manifests, SQL, and Datalog reflect the spirit of separating *what* from *how*
- **Domain-driven design**: Treating essential state as a first-class modeling concern echoes the paper's distinctions
- **Distinguishing state from logic**: A common refrain in modern architectural discussions, from clean architecture to functional core / imperative shell
## Limitations and Critiques
- **FRP as proposed has not been built**: The architecture is largely a thought experiment; no widely-adopted system implements it directly
- **Real systems need state**: Performance, integration, and external interfaces all require mutable state somewhere; the paper acknowledges this but offers limited concrete guidance for the boundary cases
- **Defining "essential" is hard**: The line between essential and accidental complexity is not always crisp and may shift as the problem is better understood
## Why It Matters
*Out of the Tar Pit* gave the software community a precise vocabulary for discussing complexity and a clear normative stance: most accidental complexity comes from state and control, and we should treat their reduction as a primary engineering goal. Even if FRP itself remains hypothetical, the paper's influence is visible in the rising popularity of functional patterns, immutable data, and declarative tools across the industry. It is essential reading for anyone serious about software design.