Software architecture diagrams are usually neat because nobody puts the emergency shell script, duplicate database, one terrifying global variable, and the service Bob wrote in 2017 but nobody is allowed to restart on the diagram.
Brian Foote and Joseph Yoder gave that other architecture a name: Big Ball of Mud.
The paper grew out of the software-patterns community in the 1990s and was presented in connection with PLoP ’97. Its central observation was uncomfortable precisely because it was obvious: the most common software architecture was not the carefully layered, elegantly decoupled system celebrated in books and conference talks.
It was the sprawling one.
The authors describe a Big Ball of Mud as a haphazardly structured system shaped by expedient repair, piecemeal growth, shared information, duplicated knowledge, and code that survives because changing it cleanly is harder than adding one more patch.
The site still preserves the paper, related presentations, and later commentary around it.
Bad architecture can still be successful software
The interesting part of the essay is that it does not simply shout “bad programmer” and go home.
Foote and Yoder examine why these systems appear.
They discuss patterns such as Throwaway Code that was never actually thrown away and Piecemeal Growth where useful systems expand one local decision at a time. A prototype succeeds. Somebody adds a feature. Then another. Customers depend on it. Deadlines become real. The temporary structure acquires a payroll department.
That is a much more useful explanation than pretending every ugly codebase was produced by people who had never heard of abstraction.
The paper also asks why there is such a large gap between the architecture software engineers say they value and the architecture that is routinely deployed.
That question has aged remarkably well.
Modern stacks have containers, cloud orchestration, service meshes, event buses, generated clients, twelve flavors of observability, and enough YAML to wallpaper a municipal building. None of those technologies abolish deadline pressure, organizational boundaries, legacy dependencies, or the human tendency to make the smallest change likely to survive Friday.
The vocabulary changed. The mud remains damp.
The site is useful in 2026 not just because the essay became influential, but because the original Web presentation remains surrounded by the intellectual neighborhood that produced it: related papers, talks, archives, and Brian Foote’s later reflections on why the idea kept resonating.
CacheRat’s 1,967 Ancient Web Domains research list includes pages like this because some old websites preserve the moment a useful idea acquired the words everybody still uses for it.
Your architecture diagram may say “platform.”
The repository knows what it is.