Big ball of mud

In computer programming, Big Ball of Mud is a term for a system or computer program that has no real distinguishable architecture. It usually includes more than one of the other anti-patterns.

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

"A Big Ball of Mud is a haphazardly structured, sprawling, sloppy, duct-tape-and-baling-wire, 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."

Big Ball of Mud systems were usually developed over a period of time with different individuals working on various pieces and parts. Expediency plays a major role. Systems developed by people with no formal computer architecture or programming training often fall into this pattern.

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 for the moment. However, programs of this pattern become maintenance nightmares.

Programmers in control of a big ball of mud project are strongly encouraged to study it and to understand what it accomplishes and use this as a loose basis for a formal set of requirements for the new well architected system that would be developed to replace the former. Technology shifts (client-server to web-based, file-based to database-based, etc.) can provide good reasons to start over from scratch.

In discussion of the Lisp programming language the term is used differently. It is used to describe the malleability of a lisp system. In lisp it is generally possible to:-

• Redefine most of the standard routines provided by the language
• Execute parts of a program at compile time rather than runtime
• Write macros that can perform arbitrary transformation on code
• Redefine most of the language syntax
• Save a System Image of a modified Lisp implementation for future use.

Forth has also being described as a ball of mud because it too has many of these properties.

Allegedly, Joel Moses coined the phrase in the 1970s: "APL is like a diamond. It has a beautiful crystal structure; all of its parts are related in a uniform and elegant way. But if you try to extend this structure in any way - even by adding another diamond - you get an ugly kludge. LISP, on the other hand, is like a ball of mud. You can add any amount of mud to it and it still looks like a ball of mud."

There is controversy over whether Moses in fact said this. The phrase may be derogatory, may be praise or may be explanation.

External link

• Big Ball of Mud (1999 paper)

References

• [1]
• Guy L. Steele, Jr. & Richard P. Gabriel The Evolution of Lisp [2], note on reference 128