Code Reads #12: “Big Ball of Mud”

This is the twelfth edition of Code Reads, a series of discussions of some of the central essays, documents and texts in the history of software. You can go straight to the comments and post something if you like. Here’s the full Code Reads archive.

“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]