Big ball of mud

From Wikipedia, the free encyclopedia
Jump to: navigation, search

A big ball of mud is a 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 turnover and code entropy. They have therefore been declared a design anti-pattern.

In computer programs[edit]

The term was popularized in Brian Foote and Joseph Yoder's 1997 paper of the same name, which defines the term:

"Big ball of mud" systems have usually been developed over a long period of time, with different individuals working on various pieces. Systems developed by people with no formal architecture or programming training often create such systems.[citation needed].

Another cause of "big ball of mud" software is when managers put pressure on developers and ask them to write the system's code one part at a time and come with incremental micro requirements instead of providing a clear description of the problem to be solved[citation needed].

Foote and Yoder do not universally condemn "big ball of mud" programming, pointing out that this pattern is most prevalent because it works, at least at the moment it is developed. However, such programs can become very difficult to maintain[citation needed].

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.

In programming languages[edit]

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 macros that give you control over the language syntax, so that the notation looks closer to the problem's domain
  • Use a data-directed programming style
  • Execute parts of a program at compile time rather than runtime
  • Save a system image of a modified Lisp implementation for future use

The programming language Forth has also been described as a ball of mud because it too has many of these properties.

Joel Moses may have coined the phrase in the 1970s:[1]

"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."

Joel Moses strongly denies saying this, claiming he instead called Lisp a bean bag because it always returns to its original shape.[2]

See also[edit]


  1. ^ Richard P. Gabriel and Guy L. Steele (1996). "The Evolution of Lisp". ACM History of programming languages—II 28 (3): 233–330. doi:10.1145/155360.155373. 
  2. ^ Thomas J. Bergin and Richard J. Gibson (1996). "Supplemental material from HOPL II". ACM SIGPLAN Notices: 9–20. doi:10.1145/240964.1198155. 


  • Guy L. Steele, Jr. & Richard P. Gabriel The Evolution of Lisp [1], note on reference 128
  • Brian Foote and Joseph Yoder, Big Ball of Mud Fourth Conference on Patterns Languages of Programs (PLoP '97/EuroPLoP '97) Monticello, Illinois, September 1997