Big Ball of Mud

In computer science, Big Ball of Mud referred ( German: big mud ball ) software, which has no recognizable software architecture. The most common causes are insufficient experience, lack of understanding of software architecture, turnover of staff and pressure on the implementation team. Although such systems Wartbarkeitsgründen are undesirable, they are still common, therefore Big Ball of Mud is considered anti-pattern of the software architecture.

Software

The term " Big Ball of Mud " was coined by Brian Foote and Joseph Yoder in their 1999 published article of the same name. You define Big Ball of Mud 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 what it june have eroded beyond recognition. Programmers with a shred of architectural sensibility shun synthesis Quagmire. 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 the synthesis failing dikes, are content to work on seeking system. "

" A Big Ball of Mud is a haphazardly structured, expansive, sloppy, fixed with duct tape and baling wire laced together spaghetti code jungle. Such systems tend to unrestrained growth and need ongoing support. The information contained in these systems are distributed randomly over the most distant elements, often to the point where almost all the important information is global or duplicated. The architecture of such systems has been defined perhaps never right, and if they do it is eroded beyond recognition. Programmers with a shred of architectural sensibility shun such swamps. Only those who do not care about architecture and maybe even like each day laboriously filling gaps in leaky dikes, enjoy working with such systems. "

Big -Ball -of- Mud systems are usually developed over a long period of time by different people without overview of the overall system. There was no architecture defined or no one cares about compliance with the defined architecture. Systems, which are implemented by developers without training and experience in software architecture, often develop into big- ball -of- mud systems.

Foote and Yoder show that such systems are not generally rejected, as it in software development in practice - albeit with enormous costs - work. In later phases, such as testing and maintenance, however, must be reckoned with enormous costs. The funds for this, however, are usually easier to set up than for it to replace the system with a high-risk, completely new development.

As an alternative to a continuation of Big -Ball -of- Mud - projects or a new development is a refactoring of the architecture. First, the target architecture of the system in the sense of large-scale architectural components such as layers or components is redefined, then assigned to the components of the target architecture, the existing modules such as classes, interfaces and packages and finally identified the forbidden according to the target architecture dependencies. Based on this target-actual comparison after the banned dependencies can be resolved gradually. This can be done for example by reversing the dependencies ( dependency inversion ). Thus, the Big Ball of Mud - architecture can be successively transferred to a defined new architecture without the professionalism included in the software to lose or take the risk of new development.

Programming languages

In the discussion on the LISP programming language, the term Big Ball of Mud is used differently. Here he referred to the possibility of shaping a Lisp system. In Lisp, it is possible by means of macros to extend the syntax of Lisp to Lisp similar to adapt a domain-specific language to the professionalism of the application. Furthermore, one can in Lisp program components at compile time, rather than run at runtime or create a memory dump of a modified Lisp system.

The Forth programming language has properties similar to Lisp and is therefore also referred to as the Big Ball of Mud.