Three Ways to Overcome a Big Ball of Mud Software Architecture

Most of the time when people think of high-level software architecture, they think of patterns like Microservices (see our previous blog post What is a Microservices Architecture?"). But the most common software architecture we see when talking to prospects and customers is the Big Ball of Mud architecture. In this post we will define the Big Ball of Mud architecture, discuss why it happens in development, and explore three way of dealing with it (hint: one is refactoring).

What is a "Big Ball of Mud"?

The term was made popular by Brian Foote and Joseph Yoder in their 1997 paper of the same name ("Big Ball of Mud"). They define a Big Ball of Mud as a casually, even haphazardly structured system that is sloppy and sprawling. The code is overly complex and tangled, and is sometimes referred to as spaghetti code. It's generally incomprehensible and lacks any perceivable architecture.

How does it come about?

We are not here to judge anyone. We've all written code we are not proud of or code we cringe at when reading later. Software economics often conspire against us, especially early in the software development process. Time and money are in short supply so we ignore software architecture and other software best practices. Benefits of a high-level architecture are typically realized late in the SDLC when maintainability and modularity become more important. The goal of the typical software project is to deliver quality software on time and under budget. Therefore we focus first on features and functionality, then focus on architecture and performance. As Kent Beck said "Make it work, make it right, make it fast". This is how we end up with a Big Ball of Mud. The structure may have never been defined or the architecture has eroded beyond recognition because of unregulated growth and repeated "quick" fixes. Maybe the project started with some throwaway code that was never intended for production use. Maybe the code was continually added to and fixed but never redesigned. "Just keep it working at all costs; we are too busy to worry about software architecture and other niceties" is the typically refrain. Big Balls of Mud are also created when a well-defined architecture erodes. The architecture works well for the requirements it was written against but when those requirements change this can, and frequently does, undermine the entire structure.

Three ways to overcome the Big Ball of Mud

Facing a Big Ball of Mud can be a daunting challenge. From our experience there are three ways to deal with it:

A. Wallow in the muck (all hail the all powerful Big Ball of Mud)

Some developers enjoy working with overly complex code and hard to use systems. If you are one of those developers, you might like The International Obfuscated C Code Contest (IOCCC). This is a computer programming contest for the most creatively obfuscated C code. According to the website, they will be accepting entries in mid-2017 for the 25th IOCCC.

B. Throw away your source code and start over again

This can be a hard pill to swallow, but if a software system's complexity is allowed to increase unchecked it will eventually reach a point where developers can no longer cope with it. Once simple repairs become all day affairs, management can no longer forecast fixes or features. It is time to consider drastic measures, but this should be the option of last resort.

C. Refactor, repair, and enhance the software system's architecture

The mortal enemy of mud is sunshine, so one of the most effective ways to overcome a Big Ball of Mud is to visualize it. The easiest way to visualize a large complex software system is with a Dependency Structure Matrix.
Dependency Structure Matrix
See our video on using a DSM with a software system: How to Read a Dependency Structure Matrix and Apply Partitioning".

A good visual representation of the software sets the stage for refactoring, repair, and rehabilitation. The first step on the road to a better architecture is to identify the disordered parts of the system and to get a handle on them. Find those sections of the code that seem less tightly coupled and start drawing architectural boundaries there. Then you can perform what-if analysis. What if I add or delete an abstraction? What if I remove the dependency between these two sections? For more information on how we tackle refactoring check out our Refactoring page. To counteract the Big Ball of Mud, a permanent commitment to consolidation and refactoring must be made. Refactoring is the primary means by which programmers maintain order in the software system. The goal of refactoring should be to leave the system working as well after a refactoring as it was before refactoring.

During software development it is perfectly natural to write messy/sloppy code, but just as your mom used to nag you to clean up your room, you should always clean up after yourself when you write software (refactor). A sustain commitment to refactoring can keep a software system from becoming a Big Ball of Mud. Also, where possible, architectural erosion should be prevented, arrested or even reversed. The project is that opportunities and insights into architecture typically happen only later in the software development process so Big Balls of Mud can be quite common.

Finally, the quality of one's tools can influence a software system's architecture. If a software system's architecture goals are inadequately communicated and visualized among team members, they are harder to take into account as the software is developed. See how Lattix Web makes communication easy in the Lattix Web demo site.