This presentation was created for the SATURN conference series and does not necessarily reflect the positions and views of the Software Engineering Institute.
While much attention had been
focused on high-level software architectural patterns, what is, in effect, the
de facto standard software architecture has seldom been discussed: the Big Ball
of Mud. A Big Ball of Mud is a haphazardly structured, sprawling, sloppy,
duct-tape-and-baling-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. Somewhat to our astonishment, since our original
statement, no one has ever undertaken to dispute this premise. 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? And how can we make such systems better?