Big Ball of Mud
Over ten years ago, Joe Yoder and I opined that, while much attention had been focused on high-level software architectural patterns, what was effect, the de-facto standard software architecture had seldom been discussed: the Big Ball of Mud (http://www.laputan.org/mud/mud.html).
It has become, God help us, our best known work. And, somewhat to our amazement, since then, no one has ever undertaken to dispute this premise.
A Ball of Mud is a haphazardly structured, sprawling, sloppy, duct-tape and bailing wire, spaghetti code jungle . We’ve all seen them. 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.
Still, this approach endures and thrives. Why is this architecture so popular? Is it as bad as it seems, or might it serve as a way-station on the road to more enduring, elegant artifacts? What forces drive good programmers to build ugly systems? Can we avoid this? Should we? How can we make such systems better?
This “Ball of Mud” conjecture was born during the first flowering of what became the Agile movement during the late nineties, and held out the hope that these notions might offer one way to escape these swamps.
Does agility offer a way out, or does it instead lead to a blitzkrieg sprint to the edge our ability to cope with complexity that ends in the muddy trenches? Is sustainable code cultivation possible, or desirable? Or are slash-and-burn practices the once-and-future state of the art?
I’ve given two earlier talks with this same title, the latest being an invited talk at OOPSLA 2007. I expect that this talk will bear only a superficial resemblance to that one.