big ball of mud

programmingops culture

A system with no discernible architecture - haphazardly structured, sprawling, and held together by expedience.

Foote and Yoder named it as the de facto most common architecture: not designed but accreted, patch upon patch, until structure is whatever survived. The uncomfortable insight is that it often wins in the short term, which is exactly why it is so widespread.

The big ball of mud is a 1997 paper by Foote and Yoder describing the most common software architecture in the world: no discernible structure, everything connected to everything, information shared promiscuously between modules that were never meant to know about each other.

What makes the paper valuable is that it refuses to be simply dismissive. It asks why this architecture dominates, and answers honestly: it works. Mud is fast to start, requires no upfront design agreement, accommodates any requirement without argument, and ships. Elegant architectures are expensive to establish and can be wrong; mud is never wrong because it makes no claims. The forces producing it are economic rather than stupid.

The cost arrives later and is paid by different people. Change becomes unpredictable, effects propagate to places nobody expected, and the cost per feature rises until it dominates the budget. Recognizing the pattern is worth more than condemning it: mud is a rational choice for a prototype whose lifetime is short, and a catastrophic one for a system that turns out to live for fifteen years, which is most of them.

Also known as: big ball of mud, BBoM

← All glossary entries