"
Big Ball of Mud" is a brilliant, meandering and very readable essay on
software design by
Brian Foote and
Joseph Yoder, of the Department of
Computer Science,
University of Illinois at Urbana-Champaign. It was written in
1997. It's on the web; a
google search for " "ball of mud" software" will bring up several links to it. It fits roughly into the body of literature on
design patterns and
antipatterns. If you are into that at all, you should read it.
The essay discusses software design from the point of view not of theory and best practice, but from the point of view of what's out there – every program that runs has a de-facto software architecture, even if, as is often the case, no deliberate design work has been done. "the most frequently deployed architecture", and "the de-facto standard software architecture" is the unstructured and piecemeal approach, like a big ball of mud.
A BIG BALL OF MUD is haphazardly structured, sprawling, sloppy, duct-tape and bailing wire, spaghetti code jungle. We've all seen them. Their code shows 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 them. 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.
The essay is not however entirely negative about balls of software-mud. It may be the dominant architecture pattern in production software. The essay attempts to describe the forces that bring about balls of mud, and asks if a solution is necessary. You cannot compromise the design of a ball of mud. It is already compromised. Throwing mud at it doesn't hurt it, it just makes it bigger.
I am not going to try to summarise this highly quotable essay, just recommend again that you read it if you are interested in the art of software construction.
Here are a few more quotations, to give a flavour:
Shantytowns are squalid, sprawling slums. Everyone seems to agree they are a bad idea, but forces conspire to promote their emergence anyway. What is it that they are doing right?
A homeowner might erect a temporary storage shed or car port, with every intention of quickly tearing it down and replacing it with something more permanent. Such structures have a way of enduring indefinitely.
Most cities begin as settlements, subdivisions, docks, or railway stops. ... The founders of these settlements never stopped to think that they were founding major cities. Their ambitions were usually more modest, and immediate.
"Make it work. Make it right. Make it fast."
- Kent Beck, 1997, explaining that the order of priorites is functionality, then design and then performance.
When it comes to software architecture, form follows function. The distinct identities of the system's architectural elements often don't start to emerge until after the code is working.
Premature architecture can be more dangerous than none at all, as unproved architectural hypotheses turn into straightjackets that discourage evolution and experimentation.
Worse is better
It is not our purpose to condemn BIG BALLS OF MUD. Casual architecture is natural during the early stages of a system’s evolution. The reader must surely suspect, however, that our hope is that we can aspire to better.