A Big Ball of Mud is a haphazardly structured, sprawling, sloppy, duct-tape-and-baling-wire, spaghetti-code jungle. These systems show unmistakable signs of unregulated growth, and repeated, expedient repair. Information is shared promiscuously among distant elements of the system, often to the point where nearly all the important information becomes global or duplicated.
The overall structure of the system may never have been well defined.
If it was, it may have eroded beyond recognition. Programmers with a shred of architectural sensibility shun these quagmires. Only those who are unconcerned about architecture, and, perhaps, are comfortable with the inertia of the day-to-day chore of patching the holes in these failing dikes, are content to work on such systems.
Brian Foote and Joseph Yoder, Big Ball of Mud
With this definition you can see that Big Ball of Mud is an Anti-Pattern of software design, you have certainly worked, work or will work on a project with these characteristics. The truth is that every day Big Ball of Mud is created, Big Ball of Mud are extremely common in our industry.
Factors such as, financial and time pressure, unqualified or inexperienced developers, changing requirements, changing developers and many other factors contribute to the creation of Big Ball of Mud.
Case study
Of course, the reasons I cited contribute to the construction of the Big Ball of Mud.
However, there is one reason that I consider the main one for the creation of the Big Ball of Mud, that is the lack of the Strategic Design of the DDD.
For this failure the Big Ball of Mud is born even before the project has its first line of code.
For example, let’s imagine building a Time Tracker system, which allows employees to record time spent on tasks or projects.
So far everything has gone well, let’s imagine that the main concepts of our Product were well defined, the Strategic Design was successful, as well as the Tactical Design.
And then new ideas emerge for the project, new concepts begin to emerge, such as expenses, teams, invoices, integrations.
And more concepts begin to emerge …
Stop right now!
Can you see the problem you are creating? The main concepts of the product began to blend, Bounded Contexts were not defined, terms in duplicity, language tainted, everything becomes confused.
That’s when we realized that a Big Ball Of Mud was created.
How to manage Big Ball Of Mud?
Even if you are able to avoid creating a Big Ball of Mud you may need to integrate with a Big Ball of Mud.
If you’re working on a Big Ball of Mud do refactoring as fast as possible.
If you are working on a project and need to integrate with a Big Ball of Mud, my suggestion is that you come back and reread what I say about DDD’s Strategic Design, Context Maps, specifically Anti Corruption Layer, which is the scenario where client (downstream) creates an intermediate layer that communicates with the upstream context, so you will not contaminate your model.
Whatever you do, do not speak that language!
See you soon!
