On The BIG BALL OF MUD

A BIG BALL OF MUD is a casually, structured system, whose organization or lack of organization, is rather dictated by expediency than design. Its success and popularity speak of the BIG BALL OF MUD, as architecture in its own right. However, the big questions still remain: why these kinds of systems are architecturally undistinguished and still so popular, what makes good programmers build ugly systems, and what can we do to improve them?

The root cause of BIG BALLS OF MUD is complex. Factors as the time constraints, the cost of investing in the architecture of a new domain (whose benefits are initially hard to estimate), the experience and skill of the designer, the inherent complexity of the application domain and the scalability issues associated with design decisions can all contribute to the appearance of the BIG BALLS OF MUD. The very nature of software architecture as hypothesis about the future, that holds that subsequent change will be confined to that part of the design space encompassed by that architecture, seems to give a philosophical explanation for the existence of BIG BALLS OF MUD architecture.

From systems emerging from quick-and-dirty code (THROWAWAY CODE), that was intended to be used only once and then discarded to those with well-defined architectures, the architectures are all prone to structural erosion. With time, those clean architectures may become overgrown as PIECEMEAL GROWTH gradually allows elements of the system to sprawl in an uncontrolled fashion. And the only way to deal with entropy in software is to refactor it. A sustained commitment to refactoring can keep a system from subsiding into a BIG BALL OF MUD. It is also important to KEEP IT WORKING, from the point of designing a change, through implementation, testing and maintenance. By taking small design steps in any direction, we can make sure that it is never more than a few steps back to a working system. Daily builds or keeping around the last working version are successful maintenance practices. The importance of testing in keeping a working system is emphasized by both the traditional Waterfall approach as well as newer techniques as Extreme Programming. The dynamics of a growing architecture are very complex. The system itself and all of its components evolve at different rates, with the general tendency for the components that change faster to become distinct from those employing slow changes. The SHEARING LAYERS form between the components and identifying these layers, understanding component interactions and grouping components based on how similar their change rates are, help balancing adaptability and stability, forces that are usually in constant tension. Often times, when facing the mess of the BIG BALL OF MUD, the architect should choose between SWEEPING IT UNDER THE RUG and RECONSTRUCTION. However, distilling meaningful abstractions from a BIG BALL OF MUD is a difficult and demanding task, requiring skill, insight, and persistence. At times, RECONSTRUCTION may seem like the less painful course.

In the end the authors note that there are good reasons that good programmers build BIG BALLS OF MUD and accept that expedient programming is, in fact, a state-of-the-art strategy. While they agree that, casual architecture is natural during the early stages of a system’s evolution, the authors also hope that at least there are ways that we can do better. The key to finding those ways is learning about the domain and the architectural opportunities looming within it, as the system grows and matures.