A Big Ball of Mud Revisited

In 1999, Brian Foote and Joseph Yoder published a paper titled "Big Ball of Mud". In their paper, they state that the Big Ball of Mud is the "most frequently deployed of software architectures." Their description of a Big Ball of Mud is widely quoted.

"A BIG BALL OF MUD is haphazardly structured, sprawling, sloppy, duct-tape and bailing wire, spaghetti code jungle. We’ve all seen them. 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."

Sadly, twenty-seven years after that paper was published, it has been my experience that this anti-pattern is still very prevalent.

Why does this keep happening? What can we do to prevent it? In my other blog posts, I cover various mistakes that I have seen and sometimes made. I also present ideas for how we can write better software and avoid a Big Ball of Mud. My posts are by no means exhaustive, but I hope they can be of value.

The best place to start is with my next blog post Architecture Matters.