Big Ball of Mud
Big Ball of Mud
Brian Foote<br>and Joseph Yoder
Department<br>of Computer Science<br>University<br>of Illinois at Urbana-Champaign<br>1304 W. Springfield
Urbana, IL 61801 USA
foote@cs.uiuc.edu<br>(217) 328-3523<br>yoder@cs.uiuc.edu<br>(217) 244-4695
Saturday, June 26, 1999
Fourth Conference on Patterns Languages of<br>Programs (PLoP<br>'97/EuroPLoP<br>'97)<br>Monticello, Illinois, September<br>1997<br>Technical Report #WUCS-97-34 (PLoP<br>'97/EuroPLoP<br>'97), September<br>1997<br>Department of<br>Computer Science, Washington<br>University<br>Chapter 29<br>Pattern<br>Languages of Program Design 4<br>edited by Neil Harrison, Brian Foote, and Hans Rohnert<br>Addison-Wesley, 2000
This volume is part of the Addison-Wesley<br>Software Patterns Series.
This paper is also available in the<br>following formats:<br>[PDF] [Word] [RTF]<br>[PostScript]
Also by Brian<br>Foote<br>and Joseph Yoder
Architecture,<br>Evolution, and Metamorphosis<br>The Selfish Class
This paper was twice featured<br>in Slashdot
Contents
Abstract<br>Introduction<br>Forces<br>Big Ball Of Mud<br>Throwaway Code<br>Piecemeal Growth<br>Keep It Working<br>Shearing Layers<br>Sweeping It<br>Under The Rug<br>Reconstruction<br>Conclusion<br>Acknowledgments<br>References
Abstract
While much attention has been focused on high-level software<br>architectural patterns, what is, in effect, the de-facto standard<br>software architecture is seldom discussed. This paper examines this<br>most frequently deployed of software architectures: the BIG BALL OF MUD. A BIG BALL OF MUD is a casually, even<br>haphazardly, structured system. Its organization, if one can call it<br>that, is dictated more by expediency than design. Yet, its enduring<br>popularity cannot merely be indicative of a general disregard for<br>architecture.
These patterns explore the forces that encourage the emergence of a BIG BALL OF MUD, and the undeniable<br>effectiveness of this approach to software architecture. What are the<br>people who build them doing right? If more high-minded architectural<br>approaches are to compete, we must understand what the forces that<br>lead to a BIG BALL OF MUD are, and<br>examine alternative ways to resolve them.
A number of additional patterns emerge out of the BIG BALL OF MUD. We discuss them in<br>turn. Two principal questions underlie these patterns: Why are so many<br>existing systems architecturally undistinguished, and what can we do<br>to improve them?
Introduction
Over the last several years, a number of authors [Garlan & Shaw<br>1993] [Shaw 1996] [Buschmann et. al. 1996] [Meszaros 1997] have<br>presented patterns that characterize high-level software<br>architectures, such as PIPELINE and LAYERED ARCHITECTURE. In an ideal<br>world, every system would be an exemplar of one or more such<br>high-level patterns. Yet, this is not so. The architecture that<br>actually predominates in practice has yet to be discussed: the BIG BALL OF MUD.
A BIG BALL OF MUD is haphazardly<br>structured, sprawling, sloppy, duct-tape and bailing wire, spaghetti code jungle.<br>Weve all seen them. These systems show unmistakable signs of<br>unregulated growth, and repeated, expedient<br>repair. Information is shared promiscuously among distant elements of<br>the system, often to the point where nearly all the important<br>information becomes global or duplicated. The overall structure of the<br>system may never have been well defined. If it was, it may have eroded beyond<br>recognition. Programmers with a shred of architectural sensibility<br>shun these quagmires. Only those who are unconcerned about<br>architecture, and, perhaps, are comfortable with the inertia of the<br>day-to-day chore of patching the holes in these failing dikes, are<br>content to work on such systems.
Still, this approach endures and thrives. Why is this<br>architecture so popular? Is it as bad as it seems, or might it serve<br>as a way-station on the road to more enduring, elegant artifacts? What<br>forces drive good programmers to build ugly systems? Can we avoid<br>this? Should we? How can we make such systems better?
We present the following seven patterns:
BIG BALL OF MUD
THROWAWAY CODE
PIECEMEAL GROWTH
KEEP IT WORKING
SHEARING LAYERS
SWEEPING IT UNDER THE RUG
RECONSTRUCTION
Why does a system become a BIG<br>BALL OF MUD? Sometimes, big, ugly systems emerge from THROWAWAY<br>CODE. THROWAWAY CODE is<br>quick-and-dirty code that was intended to be used only once and then<br>discarded. However, such code often takes on a life of its own,<br>despite casual structure and poor or non-existent documentation. It<br>works, so why fix it? When a related problem arises, the quickest way<br>to address it might be to expediently modify this working code, rather<br>than design a proper, general program from the ground up. Over time, a<br>simple throwaway program begets a BIG<br>BALL OF MUD.
Even systems with well-defined architectures are prone to structural<br>erosion. The relentless onslaught of changing requirements that any<br>successful system attracts can gradually undermine its structure.<br>Systems that were once tidy become overgrown as PIECEMEAL GROWTH gradually allows<br>elements of the system to sprawl in an uncontrolled fashion.
If such...