Big Ball of Mud (Digest)

A few years ago Brian Foote and Joseph Yoder wrote an oft-quoted paper about the here-to-fore undocumented Big Ball of Mud architectural design pattern. While the tone of their paper is undeniably satircal, the issues they raise are all-too-real. Because the complete paper is fairly long (with examples, explorations, and surveys of related work), I have prepared a very brief digest of its key messages.

The title of this pattern distinguishes it from other better known structural metaphors like PIPELINE and LAYERED ARCHITECTURE:

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.

The basic message of the paper is that unless we are continuously and actively diligent in the development and maintenance of system architecture, inexorable forces and entropy-driven processes will inevitably reduce any system to a big ball of mud. Developing and maintaining a good architecture is both difficult and expensive ... but maintaining a product without a good architecture is (over the long term) much more difficult, and much more expensive.

Most of the paper is a detailed (and humorous) examination of those forces and processes, and of a few paths to salvation.

Anti-Architectural Forces

There are powerful forces in operation that oppose the creation of good architecture:

• time
  Architecture takes time, and increased time to market usually translates into reduced opportunity. Thus business forces tend not to allow the time that architecture requires.
• cost
  Architecture costs money. The savings associated with not investing in architecture are immediate, while the costs come due at a later (much sooner than you might think). Hence, the pursuit of short term pay-offs, further reduces our willingness to make expensive investments that will only pay-off in the long term (like architecture).
• skill and experience
  Different people have different levels of skill and experience, and a deeper understanding of the problems and tools results in a much better architecture. It is hard to find people with the skill and experience to well-design complex things, so they wound up being designed by people with less skill and experience.
• inherent complexity
  The larger the system, the more difficult it is to manage its complexity (see skill and experience).
• scale
  Many people come up with solutions that make sense in a small environment, but break down at scale (see skill and experience). In part this is due to lack of experience (with large systems) but many people have observed that there are emergent phenomena in large systems that simply do not happen in smaller systems.

Proceses that give rise to Big Balls of Mud

• Shanty Towns
  Shanty Towns are easily built by unskilled labor with inexpensive materials, but the buildings are weak, function poorly, and require continuous maintenance. The same is true of much software ... where there is great pressure to get something out there as quickly as possible, and great resistance to investing up-front in design and infrastructure.
• ThrowAway Code
  Much software is written, knowing that it is not suitable for production use ... but once it exists time pressures create a powerful incentive to ship it as is rather than rewriting it. Again, the time and cost savings are immediate, while the expenses are in the future.
• Piecemeal Growth
  Up-front Top-Down design is doomed to failure because of the impossibility of properly anticipating all future requirements. When new requirements arise that are not naturally handled within the existing architecture a choice must be made between rearchitecting to meet new requirements or kludging together a one-off solution that will kind-of-work. Since the latter option is usually (in the short term) the more expedient, the system becomes dominated by these bolted-on extensions and there ceases to be any useful architecture.
• Keeping it Working
  Our software is critical, and major changes are sure to be disruptive. Therefore smaller (less disruptive) changes are far preferable to large scale changes (that would eventually solve more problems). The world of external requirements is constantly changing. If the software is not continuously adapting in response to those changes, it is on a path to obsolescence and uselessness.

Paths back towards the light

• Shearing Layers
  Software becomes good when it does a few things very well, but continuously changing requirements will demand that software be able to adapt to those changes. In a well designed system, lower level infrastructure can be very stable as peripheral and higher level functionality evolve. If designers fail to contemplate the types of change that are likely, even simple changes to requirements may require wide-spread changes throughout the product ... making all changes difficult, disruptive, and expensive.
• Sweeping it Under the Rug
  If you sweep all of the dirt into one neat pile, and then hid that pile under the rug, the room is in some sense cleaner. The same is often true of code. If you can isolate the cruft into one component, and then encapsulate it in a more reasonable set of interfaces the remainder of the system is simplified, and the code that most needs cleaning up has been gathered in a single place, making it much easier to fix. But defining that more reasonable set of interfaces requires significant architectural planning.
• Demolition and Reconstruction
  It is difficult to decide whether an old system should be repared or demolished and rebuilt from scratch. The cost and disruption may be significant, but we may now have better tools, and a better understanding of the problem that will permit us to build a much better product. If the system has become a big ball of mud, it may be too late to try to save it, and reconstruction may be the only option.