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 an engineering point of view, such systems are common in practice due to business pressures and developer turnover. 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 thus:

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

Another reason leading to produce this kind of system is when managers put pressure on developers 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, programs of this pattern become maintenance nightmares[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