Big Ball of Mud Pattern

The big ball of mud pattern is less a pattern you choose as it is a pattern you find in the real world. The big ball of mud is described by Brian Foote and Joseph Yoder in Pattern Languages of Program Design 4 [FHR99].

The big ball of mud pattern has no defined elements or relations. Big balls of mud don’t promote any qualities in particular. As you can imagine, or have yourself experienced, big balls of mud inhibit maintainability and extensibility. Both module and module and component and connector structures can be big balls of mud. Simon Brown has observed that many microservices systems can evolve into distributed big balls of mud just as easily as monolithic systems.^[10]

Since big balls of mud are found only in the real world, not on paper, the one positive thing we can say about them is that they promote short-term development speed at the cost of long-term design integrity. Big balls of mud often emerge due to undisciplined development practices and a general lack of understanding of the architectural principles at play in the software system.

Some big balls of mud are created on purpose to ship value sooner such as when a team strategically decides to accept technical debt in exchange for faster initial development. The dangers of this approach lay in not retiring or paying down the debt in a timely fashion.