“If the layered style is the most common targeted style [in software architecture], the big ball of mud style is perhaps the one most often actually achieved. It is characterized by the absence of any evident structure, or perhaps vestiges of now-eroded structure. Also typical is promiscuous sharing of information, sometimes to the extent that data structures become effectively global. Although the module, runtime, or allocation organization can be a mess, it often starts in the module viewtype and spreads elsewhere. Repairs and maintenance are expedient and resemble crude patches rather than elegant refactorings. No effort is made to enforce any conceptual integrity or consistency.
Technical debt is astronomically high. Big balls of mud can happen as a result of throwaway code that persists longer than expected, often because it was useful and therefore maintained. Another factor is tradeoffs between short-term and long-term benefits. It may be in your short-term interest to make expedient patches rather than more expensive refactorings. Unsurprisingly, such systems have poor maintainability and extensibility. It is tempting to dismiss the style as a pure anti-pattern, but Brian Foote and Joseph Yoder make the compelling argument that the style describes a good enough strategy of engineering, in the tradition of Richard Gabriel’s worse is better argument. The authors note that “Not every backyard storage shack needs marble columns.” The forces that push systems to become big balls of mud have a peculiar stability in that once a system becomes a ball of mud, some developers find security and prestige in being the select few who can understand and evolve it, while those who detest the mud (and presumably could clean it up) run away. The result is that the ball of mud is rarely cleaned up.”
“Prepare to find Mud. If you are building an architecture model in order to understand the system better, be prepared for some level of disappointment. Clarity and a story at many levels can be revealed by architecture models only if it is there to be found. Clean, well-thought-out designs are a result of careful design by the system’s developers. If the system is built as a big ball of mud then no amount of modeling will reveal anything but mud. If the system was built expediently and not refactored then expect to see a jumble of dependencies and communication paths. On the other hand, if the design is clean then models can make that evident. Another thing you should expect is exceptions to general rules such as styles and invariants. It is common for a system to be “in style X, except …” The architectural styles from books like this one are the purest expression of the style, so-called Platonic styles, but embodied styles are much more common in practice. Building an architecture model of an existing system can be effective if you set your expectations appropriately, decide in advance what questions you want to answer with the models, and build appropriate models at the right level of detail.”
These interesting quotes on how messy software architectures can be are excerpted from Just Enough Software Architecture, a book that provides guidelines and models on how to include just enough architecture in your software development activities. The topic of software architecture decay has also been discussed in Methods & Tools Spring 2009 issue in an article written by Mark Dalgarno “When Good Architecture Goes Bad“.
Reference: “Just Enough Software Architecture – A Risk-Driven Approach”, George Fairbanks, Marshall & Brainerd, 360 pages, ISBN 978-0-9846181-0-1