“Big Ball of Mud,” a 1999 paper by Brian Foote and Joseph Yoder (pdf), sets out to anatomize what it calls “the enduring popularity” of the pattern of software construction named in its title, “this most frequently deployed of software architectures,” “the de-facto standard software architecture,” “the architecture that actually predominates in practice”: a “haphazardly structured, sprawling, sloppy, duct-tape and baling wire, spaghetti-code jungle.”
This is dire stuff, and when I first glanced at “Big Ball of Mud” I thought I was in for an amusing satire — perhaps a parody of the “software patterns” school. Instead — and what I found most fascinating about the paper — the authors actually walk a fine and narrow line between a Swiftian embrace of the mud-splat school of programming and the sort of “we know better than all those idiots” arrogance that’s found in a lot of the software literature.
Despite the best efforts of “best practices” advocates and methodology gurus, mud is everywhere you look in the software field. This cannot be a coincidence or represent mere laziness. The authors ask, “What are the people who are building [Big Balls of Mud] doing right?”
Their answer: “People build big balls of mud because they work. In many domains, they are the only things that have been shown to work.”
In other words, although the Ball of Mud approach makes life painful for developers and leads to programs that are difficult to maintain or extend, it is not necessarily, or always, simply a mistake. “Not every backyard storage shack needs marble columns,” Foote and Yoder write. “There are significant fores that can conspire to compel architecture to take a back seat to functionality…”
The authors’ pragmatism compels them toward an insight that too many programming teams fail to understand: In many business scenarios, it’s far preferable to roll a Big Ball of Mud to market on time than to unveil a sparkling, architecturally sound edifice years late. “Premature architecture can be more dangerous than none at all… Money spent on a quick-and-dirty project that allows an immediate entry into the market may be better spent than money spent on elaborate, speculative architectural fishing expeditions.” (This insight is a cousin to Richard Gabriel’s “worse is better” argument.)
Foote and Yoder draw a real-world comparison to shantytowns; they’re ubiquitous because they use abundant materials and require only the most basic skills. Similarly, the Big Ball of Mud “doesn’t require a hyperproductive virtuoso architect at every keyboard.” There may even be a “secret advantage” in its “casual, undifferentiated structure”: “forces acting between two parts of the system can be directly addressed without having to worry about undermining the system’s grander architectural aspirations.”
If working programmers are doomed to encounter Big Balls of Mud throughout their careers, what can be done with them? Foote and Yoder propose three approaches: maintain and evolve (“Keep it Working”); throw it out and start over; or “surrender to entropy and wallow in the mire.” They provide in-depth discussions of the pros and cons of the first two options; they do not elaborate on the third.
Whatever approach he selects, the programmer charged with managing a Big Ball of Mud has one huge advantage over his “architecture astronaut” peer: However messy the program may be, as long as it is a functioning and deployed system, it most likely has users. And a system with users is one that provides feedback: Which problems are most urgent? Which features are most valuable? Where should you put your limited resources? The team busy building a pristine monument to architectural coherence remains in the dark on such questions as long as its aspirations to higher quality have postponed its product’s encounter with actual users.
I think that both programmers and non-programmers will find much to chew on in the frequent parallels the authors draw to architectural insights gleaned from Stewart Brand’s book How Buildings Learn (“function melts form,” “maintenance is learning”). And, as with Mitch Kapor’s Software Design Manifesto, there’s a grounding in the classical architectural principles of Vitruvius.
Architectural analogies can sometimes lead software-development theorists astray. But “Big Ball of Mud” uses them judiciously. And just as the crude mud hut has its advantages in some sites and climes, Foote and Yoder remind us not to be too quick to dismiss the crude mud balls that keep so much of our software infrastructure functioning.
[tags]code reads, software development, programming, big ball of mud, brian foote, joseph yoder, patterns[/tags]
There are no revisions for this post.
It took me a lot longer to post this one than I’d hoped. So I should point out that a couple of comments already were posted back here when I first said this was going to be the next reading…
You should take a look at The Inevitable Pain of Software Development: it’s a fascinating analysis of praxis.
I think that the problem the above architectural astronaut faces when the system is put into production, is that new requrements develop in completly different areas than he anticipated, running counter to the design of the system. Such a system may actually be worse off than the system that just was a ball of mud from the beginning, as that at least has a smaller codebase. This is especially the case in projects that try to make room for every possible functionality that they think may be added in the future into the design. This kind of thinking very often lead to failure.
Here’s my response,
Having seen impossible-to-maintain programs actually die in the field, their authors giving up on them despite continuing interest from outside, I can attest that “it still works” and “having users” do not keep a broken project working.
What part of “having users” enables a developer to add features that the users desperately want, but surpasses the developer’s capabilities to implement? You can’t say “it still works” to something that yes, works, but is laborious and error-prone to add new functionality to it because it regularly requires updating 400 almost-the-same pieces of code with a fix.
Big balls of mud don’t usually arise from competent programmers implementing well-defined requirements with forethought to future maintenance. They tend to come from the opposite: incompetent programmers, ill-defined and changing requirements and/or throw-away designs.