Big Ball of Mud
In computer science , a big ball of mud describes a program that has no recognizable software architecture . The most common causes for this are insufficient experience, a lack of awareness of software architecture, employee fluctuation and pressure on the implementation team. Although such systems are undesirable for reasons of maintainability , they are still to be found frequently, which is why the Big Ball of Mud is considered an anti-pattern of software architecture.
software
The phrase "Big Ball of Mud" was coined by Brian Foote and Joseph Yoder in their 1999 article of the same name. You define Big Ball of Mud as follows:
“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. "
“A Big Ball of Mud is a haphazardly structured, sprawling, sloppy spaghetti code jungle held together with tape and binding wire . Such systems show clear signs of unrestrained growth and constant makeshift repairs. The information contained in these systems is randomly distributed over the most distant elements, often to the point where almost all of the important information is global or duplicated. The architecture of such systems may never have been properly defined, and if so, it has been eroded beyond recognition. Programmers with a scrap of architectural sensibility avoid such swamps. Only those who do not care about architecture and who might even like to laboriously plug holes in leaky dikes every day enjoy working with such systems. "
Big ball of mud systems are usually developed over a long period of time by different people without an overview of the overall system. No architecture has been defined or nobody cares about compliance with the defined architecture. Systems that are implemented by developers without training or experience with software architecture often develop into big ball of mud systems.
Foote and Yoder pointed out that such systems should not be rejected in principle, since they work in software development in practice - albeit at enormous costs. In later phases such as testing and maintenance, however, enormous costs must be expected. However, the means for this are usually easier to set up than to replace the system with a risky, completely new development.
An alternative to continuing big ball of mud projects or a new development is to refactor the architecture. First, the target architecture of the system is redefined in terms of large architectural elements such as layers or components, then the existing modules such as classes, interfaces and packages are assigned to the components of the target architecture and finally the dependencies prohibited according to the target architecture are shown. Based on this target / actual comparison, the forbidden dependencies can then be successively resolved. This can be done, for example, by reversing the dependencies (dependency inversion). Thus the Big Ball of Mud-architecture can be gradually transformed into a defined, new architecture without the included in the software professionalism to lose or to bear the risk of a new development.
Programming languages
In the discussion of the Lisp programming language , the term Big Ball of Mud is used differently. Here it describes the designability of a Lisp system. In Lisp, it is possible, using macros , the syntax to expand from Lisp to Lisp similar to a domain-specific language adapted to the professionalism of the application. In addition, you can execute program parts in Lisp at compilation time instead of at runtime or create a memory image of a modified Lisp system.
The Forth programming language has properties similar to Lisp and was therefore also called the Big Ball of Mud .
See also
literature
- Brian Foote, Joseph Yoder: Big Ball of Mud . Ed .: Department of Computer Science, University of Illinois at Urbana-Champaign. June 26, 1999 ( laputan.org [accessed February 14, 2012]).
- Brian Foote, Joseph Yoder: Pattern Languages of Program Design 4 (= Software Patterns . Band 4 ). Addison-Wesley, 1999, ISBN 978-0-201-43304-3 , chap. 29 (English).
Web links
- Video of the talk “Big Ball of Mud” on YouTube by Brian Foote on August 28, 2007 from the Google Tech Talk Archive
Individual evidence
- ^ Brian Foote, Joseph Yoder: Big Ball of Mud . Ed .: Department of Computer Science, University of Illinois at Urbana-Champaign. June 26, 1999 ( laputan.org [accessed February 14, 2012]).
- ^ Architecture Refactoring