What is Big Ball of Mud Software Architecture?

Working with software projects in different businesses I often encounter this one, that is owned by multiple teams, or just simply by nobody. What usually happens with these over the years? Bits and pieces of functionality are getting slapped on top of their codebase with minimal possible effort. Thing is - that each layer of such changes makes the code harder to understand and fix if need be. How do professionals deal with such a problem?

#programming #tech #softwaredevelopment

Big Ball of Mud (or as we call it behind the curtain “the headache”) is an architectural antipattern that you can observe in some systems. It is often introduced unintentionally, but in some niche cases - it can be beneficial to go for it.Before I explain why - let’s focus on what it really is.
When designing a system - whether it’s a monolithic, single application, or distributed mesh of microservices, we choose some structure for it. This means we establish some critical rules, and guides on how we intend to build the system and extend it. Good architecture specifies what system is, what is it for, and how it should look like. It’ll outline system entities, their form and function, it’ll determine the system's boundary and it’ll describe relations between the entities of the system.
This may mean that some services won’t be able to talk to each other directly, or that data flows in some direction, but not the other. It may mean there will be some overhead, more work, or tasks that are coincidentally the same, but serve a different purpose. Such restrictions are limiting the speed in which the project is built and extended, but at the same time - they allow us to keep things in order. This exact order is the whole value of great architecture.
Here’s the thing: Big Ball of Mud occurs when we give those rules up. Our components are free to share data however they want, introduce low-level optimisations to high-level code, extend the functionality outside of the context they’re part of and ignore any boundaries.
Main characteristics of this antipattern are: Poorly defined domain, Mandatory Direct Communication and Clustered Deployment. Let’s dig in.
Poorly defined domain means that it’s hard to tell exactly what the component is about: it’s access points do not require all necessary data to process a task, thus leading to reaching to other components for all required information, introducing data interference.
Mandatory direct communication means not using message or event driven communication. If most tasks or all tasks have to be communicated directly there is a problem. Services are tightly coupled to each other, and require a lot of details to connect. Details are volatile.
Cluster Deployment. Ha. This is especially visible with microservices: these are the ones that have to be deployed with another microservice or they break. This makes a perfect environment for chained failures to propagate through the system: when one puzzle goes missing for a few seconds the whole solution crashes and burns.
Avoid Big Ball of Mud if you’re shipping a project that is sufficiently defined. Ditching architectural rules only makes sense if you’re already planning a rewrite, or you’re using this system as a discovery of the actual project requirements. This will allow you to write a lot of code fast, but you should plan to come back and make amends. Remember: unpaid tech debt is like all debt: it will grow interest, and one day you will have to pay. Subscribe, and I’ll see you in the next one, cheers!