A Big Ball of Mud is a software design anti-pattern in which a software system lacks a perceivable structure. This means that, to an outside observer, the system has no discernable architecture, and as such, looks thrown-together, haphazard, and is a massive pain to maintain.
Big balls of mud are extremely common in our industry. So what do we do about them?
We architect. Otherwise, we're gonna need a firehose.
The Rundown
- Name: Big Ball of Mud
- Summary: Code in a system which lacks a perceivable architecture.
- Type: Software Design
- Common?: ...Are you sure that's mud?
Give Me an Example!
Straight from the horse's mouth, as it were:
"A Big Ball of Mud is a haphazardly structured, sprawling, sloppy, duct-tape-and-baling-wire, spaghetti-code jungle. These systems show unmistakable signs of unregulated growth, and repeated, expedient repair. Information is shared promiscuously among distant elements of the system, often to the point where nearly all the important information becomes global or duplicated. The overall structure of the system may never have been well defined. If it was, it may have eroded beyond recognition. Programmers with a shred of architectural sensibility shun these quagmires. Only those who are unconcerned about architecture, and, perhaps, are comfortable with the inertia of the day-to-day chore of patching the holes in these failing dikes, are content to work on such systems."
-Brian Foote and Joseph Yoder, 1997
You know these kinds of systems. We all do. These are the systems we work in almost every day. These are the systems we, hopefully, are working to improve. These are the systems that comprise a significant chunk of software in the real world.
And that's rather a scary thought.
I know for a fact that I've worked in these systems. Hell, depending on your definition, I might be creating one of these systems right now (as I talked about in the Lava Flow post). The Big Ball of Mud, I'd be willing to argue, is the state that any software project will end up in if no attention is paid to the architecture of that system.
But what do we do about it? We architect. Otherwise, we have to bring out the fire hose of a rewrite.
Strategies to Solve
I actually believe that in modern software shops, Big Ball of Mud in the form of "this system has no architecture" is becoming less common. The advent of methodologies such as Agile which promote knowing the architecture of a system has been a boon. But there's another form of this anti-pattern, that of "An architecture exists but it sucks and needs to be changed," which will probably never go away.
For both forms, the solution is the same: implement a perceivable, flexible, appropriate architecture for any given system.
This means doing research. Research into if anyone has done a similar project before (the answer is almost always "yes") and what they did to solve that similar problem, as well as if such a solution would work for our systems. This could be as simple as reading blog posts or papers.
The problem arises when we don't do this. When we get straight to coding without figuring out an architecture or appropriate framework to work within. If this goes on long enough (read: longer than like five minutes), you will end up with a big ball of mud. In this scenario, you'll probably need to break out the firehose of a rewrite.
I've done plenty of rewrites in my time, and I can say with certainty that anyone who states "rewrites are unnecessary" is unequivocally wrong; sometimes they are the only option left. But the trick is that, during the planning for the rewrite (because you should treat rewrites as new projects themselves) be sure to do the research necessary to determine an appropriate architecture.
One of my favorite adages goes like this:
"Weeks of coding will save you hours of planning."
It's up to you where you want to spend your time.
Summary
A Big Ball of Mud occurs when a software system lacks a perceivable, flexible, appropriate architecture. It is most likely the default ending state of all software, if no attention is paid to architecture in the beginning. The best solution is prevention, which means designing the appropriate architecture in the beginning of the project; else, you're going to need to break out the firehose of a rewrite.
By the way, if you'd like an in-depth overview of the different kinds of big balls of mud, go ahead and read the original paper or Jeff Atwood's writeup on it. They're pretty interesting.
Have you found a big ball of mud? What did you do to fix it? Did you cause it, and are you willing to share? I'd like to know about it. Share in the comments! Or else head on back to the series index page to see some more anti-patterns.
Happy Coding!
