A big ball of mud is a software system that lacks a perceivable architecture. The term appears to have been coined by computer scientists Brian Foote and Joseph Yoder in a 1996 paper.
A system that is a big ball of mud can be said to be held together by duct tape, sweat, and time. It is haphazardly structured, and as such attempting to modify it may be an exercise in futility. Any modifications that were made to the system in the past were just added to the outer parts with no recognizable planning (hence the term big ball of mud; it’s like sticking some mud onto a ball of mud, which just makes the ball of mud bigger.)
Previously in this series:
Such a system often starts as a small, focused application, before scope creep and unmanageable deadlines eventually turn it into an unrecognizable beast. Because this anti-pattern results from a combination of time and non-code factors, it can be very difficult to prevent or even detect. Doing such requires someone which knowledge of the system and power to control its architecture, a combination that gets increasingly rare the longer the system exists.
Show Me An Example!
If you are a software developer, you have probably seen an example of this architecture recently. In their paper, Foote and Yoder contend that this is the most common architecture in software development.
The fact is that most software is organic and grows to meet requirement as they arise. Because of this, without some benevolent overlord architect strictly controlling how the structure of the app can grow and change as the requirements do, any software project is liable to slip into this anti-pattern. This is exactly what makes the Big Ball of Mud anti-pattern so prevalent.
#anti-patterns #big data
