Is software architecture critical, accidental, or disposable? A fascinating and amusing article at http://www.laputan.org/mud/mud.html suggests that despite the lip-service we all give to careful design, perhaps the most common structure is A Big Ball Of Mud.
Quoting from the piece: “A Big Ball of Mud is a 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 authors suggest that most systems tend towards a big ball of mud. Even the most carefully crafted applications suffer from hectic maintenance by programmers not entirely familiar with the structure. One patch becomes two; two patches become four; and over time all facets of the original design disappear in a welter of changes.
How many of us have worked on systems where, at the very least, the comments no longer mirror the code? Comment drift is the first sign of an application on its way to becoming a big ball of mud.
More likely, though, it is a product that starts with only the outline of careful architecture, which begins to disappear as developers get deeper into the project. One problem reveals other problems; and soon all that existed of the original structure is gone. We manage to get the thing out the door, but it's a mess; maintenance is guaranteed to only make things worse.
If indeed entropy is the most powerful force of all, then most code will drift into a big ball of mud. What are our options?
Jack G. Ganssle is a lecturer and consultant on embedded development issues. He conducts seminars on embedded systems and helps companies with their embedded challenges. He founded two companies specializing in embedded systems. Contact him at His website is .
I strongly agree with Ingo Knopp,as Entropy of the system is inevitable especially the system developed comes under mainstream consumer electronics product. So one can only delay the eventual “Big Ball of Mud” and you will living in “Fool's Paradise” if you think you can maintain the software forever
Srinivas Rao Kudavelly
Philips Consumer Electronics
In the book “The Mythical Man Month”, one of Brooks' propositions is “All repairs tend to destroy structure, to increase the entropy and disorder of a system. Even the most skillful program maintenance only delays the program's subsidence into unfixable chaos, from which there has to be a ground-up redesign.”
I tend to agree, even changes made while the original code is being written can destroy the structure if the code has not been written in a way that makes it easy to modify (i.e. low coupling between modules).
However, if the code was well designed, and the person maintaining the code is willing to do the work to understand the design and to maintain the structure of the code, I believe entropy can be held off. The Big Ball of Mud is not inevitable.
The idea of software-entropyis really good. The day I givemy code to anyone else is alwaysa sad moment, because I know it'sgetting worse. But there is aconcept to minimize entropy:”Design by Contract”. In aprogramming language implementingit like eiffel, I can put wallsaround my code to protect itagainst quick and dirty changesfrom unscary people. You can'tchange the time until entropyis the death of universe, but youcan stretch the time your codeis not a “Big Ball of Mud”.
“Big Balls of Mud” is a very accurate article. I have found that when most product development projects start, the road looks like a finely groomed dirt road ready for a parade. There will be some bumps, but a good architecture will handle these bumps. Then outside forces get involved (read management, marketing, etc.) and delivery dates are accelerated, the dreaded “scope creep” occurs, and budgets are cut. Consequently, the entire parade is rained upon. If we could only build a huge roof over the project to protect it, the mess that most products evolve into will not occur. Unfortunately, I have not figured out how to do this. As Chris mentions, the effort and cost to maintain spaghetti code is astronomical. If this cost could be captured, management and marketing may think twice about messing with the project.
Sr. Applied Specialist
Jack Replies: Agreed. We need to start looking at code as a business asset, one that we manage just like any important asset.
I just read “Big Balls of Mud” and it's sad but true. The remark about entropy caught my attention. It really takes a diligent, disciplined attitude to develop and maintain software. If you park a new car out in a field for a long time without attending to it it's going to decay. Consider the effort it takes just to maintain something, let alone restore it.
Member of Technical Staff