Big Ball of Mud (BBoM) architectures are viewed as the culmination of many design decisions that, over time, result in a system that is a hodgepodge of steaming and smelly anti-patterns. It can be arguably claimed that one of the reasons for the growth and popularity of agile practices is partially because the state of the art of software architectures is not that good. Agile methods, with their focus on extensive testing and frequent integration, have been shown to make it easier to deal with evolving (possibly muddy) architectures and to keep systems working while making significant improvements and adding functionality. Time has also shown that agile practices are not sufficient to prevent or eliminate Mud.
This session will examine the paradoxes that underlie BBoMs, what causes them, and why they are so prominent. I'll also explain why continuous delivery and test-driven development with refactoring are not enough to ensure clean architecture. Additionally, I'll talk about some practices and patterns that help keep the code clean. Some of these include Testing, Divide & Conquer, Gentrification, Demolition, Quarantine, Refactoring, Craftmanship, and the like. The original BBoM paper described some best practices such as Shearing Layers and Sweeping It Under the Rug as ways to help deal with muddy architectures. Additionally, other practices such as Paving over the Wagon Trail and Wiping Your Feet at the Door can make code more habitable.