View source for Big ball of mud

{{short description|Software whose source code is an incomprehensible mess}}

A '''big ball of mud''' is a [[Software system|software system]] that lacks a perceivable architecture. Although undesirable from a software engineering point of view, such systems are common in practice due to business pressures, developer [[Social:Turnover (employment)|turnover]] and [[Software entropy|code entropy]]. They are a type of design [[Anti-pattern|anti-pattern]].

==In computer programs==
The term was popularized in Brian Foote and [[Biography:Joseph Yoder (computer scientist)|Joseph Yoder]]'s 1997 paper of the same name, which defines the term:

{{bquote|
A Big Ball of Mud is a haphazardly structured, sprawling, sloppy, duct-tape-and-baling-wire, [[Spaghetti code|spaghetti-code]] jungle. 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.
|Brian Foote and Joseph Yoder
|''Big Ball of Mud.'' Fourth Conference on Patterns Languages of Programs (PLoP '97/EuroPLoP '97) Monticello, Illinois, September 1997
}}

Foote and Yoder have credited Brian Marick as the originator of the 'big ball of mud' term for this sort of architecture.<ref>{{cite web |last1=Foote |first1=Brian |last2=Yoder |first2=Joseph |url=http://www.laputan.org/mud/mud.html#BigBallOfMud |title=Big Ball of Mud |website=laputan.org |date=26 June 1999 |accessdate=14 April 2019}}</ref>

Programmers in control of a big ball of mud project are strongly encouraged to study it and to understand what it accomplishes, and to use this as a loose basis for a formal set of requirements for a well-designed system that could replace it. Technology shifts, such as client–server to web-based or file-based to database-based, may provide good reasons to start over from scratch.{{fact|date=March 2018}}

==In relation to Lisp==
In discussion of the Lisp programming language the term ''big ball of mud'' is used differently, in this case to describe the malleability of a Lisp system.  In Lisp, it is generally possible to:
* Easily write [[Macro (computer science)|macros]] that give control over the language [[Philosophy:Syntax|syntax]], so that [[Domain-specific language|the notation looks closer to the problem's domain]]
* Use a [[Data-directed programming|data-directed programming]] style
* Execute parts of a program at compile time rather than runtime
* Save a [[System image|system image]] of a modified Lisp implementation for future use
As a result of the confluence of these features, Lisp is extraordinarily flexible, even to such an extent that the language implementation itself may be completely rewritten during runtime (i.e. [[Reflection (computer programming)|reflective]] [[Metaprogramming|metaprogramming]]), which can result in Lisp systems becoming "muddy" over time due to the fluidity and ease with which they may be extended and evolve through simple use. [[Metalinguistic abstraction]], a prominent characteristic of Lisp, also allows programmers to develop entirely new and idiosyncratic conceptual vocabularies to describe the processes and functions their programs go through in tackling a problem domain, and can, if combined with poor software documentation, result in Lisp systems that work quite well and are indeed quite well-structured from a design perspective, but are only comprehensible to the original coders, or to anyone else willing to invest the time to sift through layers of [[Recursion (computer science)|highly recursive]] code.

[[Biography:Joel Moses|Joel Moses]] has been credited with coining the phrase in the 1970s:<ref>{{cite journal| title=The Evolution of Lisp | author=[[Biography:Richard P. Gabriel|Richard P. Gabriel]] and Guy L. Steele | journal=ACM History of Programming Languages—II | pages=233–330 | year=1996 | url=http://portal.acm.org/citation.cfm?id=154766.155373| doi=10.1145/155360.155373| volume=28| issue=3}}</ref>
<blockquote>[[APL (programming language)|APL]] is like a beautiful diamond – flawless, beautifully symmetrical. But you can't add anything to it. If you try to glue on another diamond, you don't get a bigger diamond. Lisp is like a ball of mud. Add more and it's still a ball of mud – it still looks like Lisp.</blockquote>

Moses strongly denies this, claiming he instead called Lisp a bean bag because it always returns to its original shape.<ref>{{cite journal| title=Supplemental material from HOPL II | author=Thomas J. Bergin and Richard J. Gibson  | journal=ACM SIGPLAN Notices | pages=9–20 | year=1996 | volume=31 | issue=11 | url=http://portal.acm.org/citation.cfm?id=1198155| doi=10.1145/240964.1198155| doi-access=free }}</ref>

==See also==
*[[Design pattern]]
*[[Spaghetti code]]
*[[Technical debt]]

==Notes==
<references/>

==References==
* Guy L. Steele, Jr. & Richard P. Gabriel ''The Evolution of Lisp'' [http://citeseer.ist.psu.edu/steele93evolution.html], note on reference 128
* Brian Foote and Joseph Yoder, [http://www.laputan.org/mud/  ''Big Ball of Mud''] Fourth Conference on Patterns Languages of Programs (PLoP '97/EuroPLoP '97) Monticello, Illinois, September 1997

[[Category:Anti-patterns]]
[[Category:Lisp (programming language)]]

{{Sourceattribution|Big ball of mud|1}}