Big Ball of Mud (BBoM) architectures are viewed as the culmination of many design decisions that, over time, result in a system that is hodgepodge of steaming, smelly anti-patterns. Yet how BBoM architectures come into existence and successfully evolve is much more nuanced. BBoMs often do not result from well-intentioned design ideas gone wrong. Nor are they simply an accretion of expedient implementation hacks. Often BBoM systems can be extremely complex, with unclear and unstable architectural boundaries and requirements. Because of their complexity, BBoM architectures are likely not understood by any single mind. They typically are fashioned out of many parts, which together comprise a sprawling whole. So BBoM systems can and do have good, as well as bad and ugly parts. Successfully deployed BBoM systems continue to work well enough, in spite of their design flaws. How can that be?
Much has happened in our industry since the original discussion and publication of the Big Ball of Mud paper in 1998. When that paper was originally published, agile methodologies such as eXtreme Programming and Scrum were just beginning to gain popularity. The growth and popularity of agile practices might be partially due to the fact that the state of the art of software architectures is so muddy. Being agile, with its focus on extensive testing and frequent integration, arguably makes it easier to deal with evolving architectures and keeping systems working while making significant improvements and adding functionality. However, although Agile has been around for quite some time, we can see that it still does not prevent Mud.
This talk will examine the paradoxes that underlie Big Balls of Mud, what causes them, and why they are so prominent. I’ll explore what agile practices can help us avoid or cope with mud. I’ll also explain why continuous delivery and TDD with refactoring is not enough to help ensure clean architecture and why it is important to understand what is core to the architecture and the problem at hand. Understanding what changes in the system and at what rates can help you prevent becoming mired in mud. By first understanding where a system’s complexities are and where it keeps getting worse, we can then work hard (and more intelligently) at sustaining the architecture. Additionally, I’ll talk about some practices and patterns that help keep the code clean or from getting muddier The original Big Ball of Mud paper described some best practices such as SHEARING LAYERS and SWEEPING IT UNDER THE RUG as a way to help deal with muddy architectures. Additionally there are some other practices such as PAVING OVER THE WAGON TRAIL and WIPING YOUR FEET AT THE DOOR that can make code more habitable.
Joe is the author of many patterns, including being an author of the Big Ball of Mud pattern, which illuminates many fallacies in the approach to software architecture.Joe currently resides in Urbana, Illinois. Joseph has taught, mentored, consulted, and managed various software projects for many years, including applying patterns, designing architecture, creating adaptive object models, utilizing agile methods, developing frameworks, refactoring existing systems, object oriented software development (in Java, C#/.NET, Smalltalk and C++), web development and cloud services.
Other projects involve working in both the Java and .NET environments deploying Domain-Specific Languages for clients. Joe presents tutorials and talks, arranges workshops, and organizes leading technical conferences held throughout the world, including international conferences such as Agile, Agile Portugal, Encontro Ágil in Brazil, AOSD, CBSoft, JAOO, QCon, PLoP, AsianPLoP, SugarLoafPLoP in Brazil, OOPSLA, ECOOP, SATURN, and SPLASH. Joe thinks software is still too hard to change. He wants do something about this and believes that with good patterns and by putting the ability to change software into the hands of the people with the knowledge to change it seems to be on promising avenue to solve this problem. Joe currently resides in Urbana, Illinois.