Big Ball Of Mud
Today I was rereading PLOP 4, and in particular the chapter by Brian Foote and Joseph Yoder on an architectural pattern they call a Big Ball of Mud. There is such wisdom and insight in their work that I just had to share some passages. Please, go amazon yourself a copy of PLOP 4 (and while you are at it, order PLOP 1, 2, 3, and 5 as well) so that you can read about their entire pattern language:Why does a system become a Big Ball of Mud? Sometimes, big ugly systems emerge from throwaway code. Throwaway code is quick-and-dirty code that was intended to be used only once and then discarded. However, such code often takes on a life of its own, despite casual structure and poor or nonexistent documentation. It works, so why fix it? When a related problem arises, the quickest way to address it might be to expediently modify this working code, rather than design a proper, general program from the ground up. Over time, a simple throwaway program begets a Big Ball of Mud. Even systems with well-defined architectures are prone to structural erosion. The relentless onslaught of changing requirements that any successful system attracts can gradually undermine its structure. Systems that were once tidy become overgrown as piecemeal growth gradually allows elements o the system to sprawl in an uncontrolled fashion. If such sprawl continues unabated, the structure of the system can become so badly compromised that it must be abandoned. ? As with anything else in the universe, counteracting entropic forces requires an investment of energy. Software gentrification is no exception. The way to arrest entropy in software is to refactor it. A sustained commitment to refactoring can keep a system from subsiding into a Big Ball of Mud. ... Some of these patterns might appear at first to be antipattterns or strawmen, but they are not, at least in the customary sense. Instead, they seek to examine the gap between what we preach and what we practice. ... Still, some of [these patterns] may strike some readers as having a schizoid quality about them. So, for the record, let us put our cards on the table. We are in favor of good architecture. Our ultimate agenda is to help drain these swamps. Where possible, architectural decline should be prevented, arrested, or reversed. ? In part, our attitude is to ?hate the sin, but love the siner.? ? Not every backyard storage shack needs marble columns. There are significant forces that can conspire to compel architecture to take a back seat to functionality, particularly early in the evolution of a software artifact. Opportunities and insights that permit architectural progress often are present later than earlier in the life cycle. A certain amount of controlled chaos is natural during construction and can be tolerated, as long as you eventually clean up after yourself. More fundamentally, a complex system may accurately reflect our immature understanding of a complex problem. The class of systems that we can build at all may be larger than the class of systems we can build elegantly, at least at first. A somewhat ramshackle rat?s nest might be a state-of-the-art architecture for a poorly understood domain. This should not be the end of the story, though. As we gain more experience in such domains, we should increasingly direct our energies to glean more enduring architectural abstractions from them.
Well said, Brian and Joseph.