What Is a Big Ball of Mud?

“Big Ball of Mud” is not exactly the kind of term you would use to open an architecture assessment in front of a steering committee. The name sounds like developer slang, perhaps even polemical. Anyone who describes their own system that way should at least expect a few questions.

Still, the term is not something developers simply made up in frustration. It comes from the software architecture and pattern literature. Brian Foote and Joseph Yoder presented their work Big Ball of Mud at the Pattern Languages of Programs Conference in 1997; it was later published in Pattern Languages of Program Design 4. Since then, the term has continued to appear in scientific software engineering literature, including work on Architecture Erosion and Design Erosion.

That does not make it a formally standardized diagnosis. There is no ISO definition, no generally accepted metric, and no threshold at which an application objectively crosses from a “normal” legacy system into a Big Ball of Mud.

Instead, the term serves as a surprisingly precise description of a structural condition.

And, above all, it describes something very different from a “monolith.”

What Foote and Yoder Meant by a Big Ball of Mud

Foote and Yoder summarize their description in a single sentence:

“A BIG BALL OF MUD is a casually, even haphazardly, structured system.”

They mean a system whose structure emerged more casually or unintentionally than through deliberate design. Its organization is driven more by short-term expediency than by a consistent architectural plan.

Foote and Yoder describe systems shaped by unregulated growth and repeated pragmatic repairs. Information is shared across distant parts of the system or duplicated in multiple places. The overall structure was either never particularly well defined or has eroded over time to the point where it is barely recognizable.

It is important to notice what the authors do not do.

They do not simply present the Big Ball of Mud as evidence of bad software engineering, nor as a moral failure of individual developers. A substantial part of their work is concerned precisely with the question of why systems like these are so common.

Because, in the short term, the decisions from which they emerge can appear entirely reasonable.

A pragmatic change is often faster than a structurally clean solution. Bypassing an existing boundary can appear cheaper than changing that boundary first. A prototype may fulfill its purpose and then simply continue to live on. An application can grow for years without every step requiring a comprehensive architectural decision.

The problem is therefore not that every individual decision must have been obviously wrong.

The problem is what the sum of those decisions eventually does to the internal structure of the system.

That ambiguity is exactly what still makes the term interesting to me today.

When Architecture Loses Its Explanatory Power

Later research describes a related process using terms such as Architecture Erosion and Design Erosion.

Li, Liang, Soliman, and Avgeriou studied how practitioners perceive Architecture Erosion. Put simply, Architecture Erosion describes a process in which the actually implemented structure of a system increasingly diverges from its intended architecture.

The authors explicitly associate one possible extreme form of this erosion with the Big Ball of Mud: a system that ultimately lacks a remaining perceivable architecture.

That phrase captures an important point.

Architecture does not necessarily disappear physically from the repository.

There are still directories. Modules. Components. Classes. Services. There may even be up-to-date architecture diagrams. Areas still have domain-oriented names. Layers are still visible in the file system.

The system looks structured.

But that visible structure explains less and less reliably how the system actually works.

Baum, Dietrich, Anslow, and Müller examine the same development from the perspective of Design Erosion. They investigate how violations of design principles can emerge and spread during the evolution of a system. In that perspective, a Big Ball of Mud is not a state that suddenly appears on a Tuesday morning, but a possible result of progressive structural deterioration.

Exactly how that process unfolds is a separate question. That is the subject of the next article.

For the purpose of defining the term, another observation is enough:

A Big Ball of Mud does not describe the external shape of a system. It describes the condition of its internal structure.

Or, more precisely:

A Big Ball of Mud is a state in which the visible or intended structure of a system explains less and less reliably how the system is actually organized.

This is not a definition by Foote and Yoder. It is a working definition for this series, derived from their original description and later research on architectural and design erosion.

An architecture can continue to exist on paper even though its boundaries have less and less effect in the actual implementation.

A Working Definition for Frontends

Applied to frontend systems, this does not mean looking for a particular technology or a particular size.

A codebase does not become a Big Ball of Mud simply because it is large, has existed for a long time, is deployed as one unit, or is developed by many people.

All of these characteristics can exist in both excellently structured and severely eroded systems.

What matters is whether the architecture still has a meaningful structuring effect.

Domain boundaries should separate responsibilities. Slices should constrain which parts of the system need to know about each other. Layers should define responsibilities and dependency directions. Interfaces should control which information is allowed to cross those boundaries.

In a Big Ball of Mud, these boundaries increasingly lose their effect.

Domain responsibilities begin to overlap. Slice boundaries may still exist in the directory tree, but constrain actual dependencies less and less. Layers still have names, but their dependency direction is no longer followed reliably. Responsibilities move between areas, and new changes are increasingly implemented wherever a technically accessible solution happens to be available.

At that point, the architecture loses one of its most important functions:

It becomes less and less useful for inferring responsibilities and the impact of changes from the structure of the system itself.

For frontend systems, I therefore use the following working definition in this series:

A frontend becomes a Big Ball of Mud when its internal structure can no longer reliably constrain or explain changes, responsibilities, and dependencies.

The directory is still called orders. The component is still located under presentation. An area is still referred to as its own domain slice.

The interesting question is simply:

Does that still mean anything?

The concrete symptoms this produces in frontend systems are a separate question. Cyclic dependencies, God Services, global state, cross-slice dependencies, or changes with far-reaching side effects deserve a much more detailed examination.

That is the subject of the later article “Recognizing It in the Frontend.”

For now, the goal is only to define the condition.

Not Every Piece of Ugly Code Is a Big Ball of Mud

Precisely because the term is so vivid, it is easy to overuse.

A class with two thousand lines can be a problem. A badly structured component can become expensive. A single God Service can represent a serious architectural issue. Technical Debt can burden development work for years.

None of these findings, on its own, is enough to meaningfully classify an entire system as a Big Ball of Mud.

Age is not a sufficient criterion either.

An old system can contain technological choices that are long outdated and still remain excellently structured from a domain perspective. Its boundaries can remain understandable even after many years. Conversely, a young codebase can develop a structure within a short period of time in which responsibilities and dependencies become difficult to understand.

The same applies to size.

A large domain model is allowed to be complex. Complexity that originates in the problem domain is not automatically an architectural failure. A codebase with thousands of files can be clearly organized, while a much smaller application may already have lost most of its meaningful internal boundaries.

Legacy software is not automatically a Big Ball of Mud either.

A legacy system can use outdated technologies, carry significant Technical Debt, and still consist of clearly separated domain areas with stable dependencies.

Big Ball of Mud should therefore remain a structural diagnosis, not a derogatory term for software we simply do not enjoy working on.

That matters especially because another term is surprisingly often used in its place during architecture discussions.

A Monolith Is Not a Big Ball of Mud

“Unfortunately, we have a monolith.”

I have heard variations of this sentence in several architecture assessments. It is usually said with a certain tone, as if the diagnosis had already been made.

Technically, however, the sentence tells us surprisingly little about the quality of the system’s internal architecture.

At the system level, a monolith primarily describes an application that is developed and delivered as one coherent unit. How that unit is structured internally is largely independent of that fact.

A modular monolith can have clear domain slices, cleanly separated responsibilities, directed dependencies, consistent layers, and stable internal interfaces.

Its outer system boundary is large.

Its internal architectural boundaries do not have to be.

One deployment does not imply one structure.

Conversely, distributing a system does not automatically improve its architecture. A system can consist of many independently deployed parts and still be tightly coupled from a domain perspective. Dependencies can remain cyclic, implicit, and difficult to constrain, regardless of whether they exist within one process or cross technical system boundaries.

Distribution is not an architectural quality. Neither is centralization.

Or, more concisely:

“Monolith” describes a system form. “Big Ball of Mud” describes a structural condition.

The two properties can occur together. But they do not have to.

An excellently structured monolith is possible.

So is a monolithically deployed Big Ball of Mud.

And a distributed system can also be a Big Ball of Mud structurally.

Deployment topology and internal architecture quality exist on different axes.

Whether a system is monolithic or distributed and how well its internal structure works are two different questions.

What People Sometimes Actually Mean by “Monolith”

That makes the sentence “Unfortunately, we have a monolith” much more interesting in assessments.

Because the person saying it is often not primarily describing the external system form.

After a few additional questions, it may turn out that “monolith” was intended to describe something else entirely: changes have difficult-to-predict side effects. Domain boundaries barely work anymore. Nobody can say with confidence which areas will be affected by a change. Certain people possess knowledge without which large parts of the system can hardly be changed safely. Small functional changes can unexpectedly propagate throughout the application.

At that point, “monolith” has become a conceptual shorthand.

That is not deception. Quite the opposite: within the project, the term may have evolved over years into a diagnostic substitute for an entire collection of structural experiences.

The responsible person says:

“We have a monolith.”

and may actually mean:

This system can barely be divided into areas that are meaningfully isolated from one another.

An external architect, however, hears — entirely correctly:

This application is developed and delivered as one coherent unit.

Both are using the same word.

They simply have completely different systems in mind.

For someone who has worked in the application for years, the term “monolith” may already carry all of their experience with problematic changes, side effects, and implicit dependencies.

For an external assessor, it does not.

A complex structural condition is compressed into a single, technically rather neutral architecture term.

And a surprising amount of information can be lost in that compression.

When the Right Word Leads to the Wrong Diagnosis

This conceptual ambiguity would merely be a linguistic footnote if it had no practical consequences.

Assessments are almost always constrained.

Time is limited. Budgets are limited. Documentation is incomplete. Not every relevant person is available. Not every codebase can be analyzed deeply within a few days. And sometimes an assessment deliberately focuses more heavily on interviews, architecture documentation, and organizational processes than on detailed structural code analysis.

If the word “monolith” repeatedly appears under those conditions, it can lead to a completely understandable conclusion:

An experienced architect knows that a monolith is not, by itself, an architectural problem.

And they are completely right.

They may simply be answering the wrong question.

I have experienced exactly this situation in an assessment myself.

I already had my own view of the system, but deliberately wanted a second perspective. So I brought in a Principal Architect without giving him my assessment beforehand. He was supposed to examine the system with as little of my bias as possible.

A substantial part of his assessment consisted of interviews with the teams and disciplines involved. The codebase, and especially its actual dependency structure, was examined much less deeply.

The same word appeared repeatedly in those conversations:

“Monolith.”

The final assessment was, roughly:

It is not actually that bad.

And based on the description he had heard, that conclusion was understandable.

After all, a monolith is not inherently a structural emergency.

A deeper examination of the actual dependencies, however, produced a very different picture. Behind the visible modules was a heavily entangled structure with large cyclic areas and a very high number of dependencies. The architecture discussed in the interviews explained only a limited part of the structure that was actually effective inside the system.

This is a personal experience, not scientific evidence that interview-based assessments inherently produce incorrect results.

But for me, it illustrates a methodological risk very clearly:

“Monolith” can unintentionally become the wrong diagnosis.

Not because the term itself is wrong.

But because it answers a different question.

When several interviewees describe a system as a “monolith,” my first concern is therefore not whether the system should be split into smaller deployments.

Other questions are more interesting:

• Are the domain boundaries inside the system still effective?
• Do the documented and implemented architectures match?
• Do dependencies follow understandable directions?
• Can responsibilities still be clearly localized?
• Do changes remain within expected boundaries?
• Are there large areas of mutual dependency?
• Does the visible structure explain which parts of the system actually depend on each other?

Only the answers to questions like these allow us to make the distinction that actually matters:

Am I looking at a large modular monolith?

Or at a Big Ball of Mud that happens to be deployed as a monolith?

Anyone who treats the two as equivalent may underestimate one while simultaneously doing the other an injustice.

The External Form Is Not the Diagnosis

The term Big Ball of Mud is drastic. That is precisely why it should be used carefully.

It does not simply describe old software, a lot of code, a monolith, or an application with Technical Debt.

It describes a structural condition.

Foote and Yoder already described systems in the late 1990s whose organization had emerged more from pragmatic growth than from consistent design. Research on Architecture and Design Erosion adds the observation that the actually implemented structure of a system can drift further and further away from an originally intended architecture.

For frontend systems, that does not mean that one violated layer rule already creates a Big Ball of Mud. Nor does it mean that every large or long-lived application inevitably ends up there.

The decisive question is whether the architecture still fulfills its structuring function.

Do slices still constrain domain responsibilities?

Do layers still have reliable meaning?

Are dependencies still understandable?

Can the visible structure of the system still tell us where a change should take place and which parts of the system may be affected?

When those statements become less and less reliable, architecture loses its practical meaning.

At some point, architecture becomes little more than labels.

And if a Big Ball of Mud is not simply a monolith, and even systems that once had a clear structure can end up in this condition, one obvious question follows:

Who built it?

The answer is often less satisfying than we might expect.

Nobody came to work one morning and decided to build a Big Ball of Mud that day.

That is exactly what the next article is about:

“Nobody Built It.”

---

Sources

Foote, Brian; Yoder, Joseph W.: Big Ball of Mud. Originally presented at the Fourth Conference on Pattern Languages of Programs (PLoP ’97), 1997; later published in: Harrison, Neil; Foote, Brian; Rohnert, Hans (eds.): Pattern Languages of Program Design 4. Addison-Wesley, 2000. Original version: https://www.laputan.org/mud/

Li, Ruiyin; Liang, Peng; Soliman, Mohamed; Avgeriou, Paris: Understanding Architecture Erosion: The Practitioners’ Perceptive. IEEE/ACM International Conference on Program Comprehension (ICPC), 2021. DOI: 10.1109/ICPC52881.2021.00037. Preprint: https://arxiv.org/abs/2103.11392

Baum, David; Dietrich, Jens; Anslow, Craig; Müller, Richard: Visualizing Design Erosion: How Big Balls of Mud are Made. IEEE Working Conference on Software Visualization (VISSOFT), 2018, pp. 122–126. DOI: 10.1109/VISSOFT.2018.00022. Preprint: https://arxiv.org/abs/1807.06136