Big Balls

"Big Balls of Mud: Is This the Best that Agile Can Do?" was one of my favorite sessions, given by Brian Foote and Joseph Yoder. It was presented as a "debate", where both of the presenters answered a series of questions given by a moderator. This session was a reflection on what I consider a fundamental problem in our profession: why is the "Big Ball of Mud" still the de-facto standard software architecture?



Most of the material presented comes from an article (41 pages) the presenters wrote called "Big Ball of Mud" (html | pdf). Big Balls of Mud are

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 architects preach better practices, with diagrams, principles, books, but in the end we still end up with mud. What makes the Big Ball of Mud software architecture so successful? Foote gives the example of Internet Explorer and Netscape, both of which he considers to be monstrous large balls of putrid mud. These products were successful, and made money. Some other examples of cleaner things that failed: Mac (smaller market share than Windows), lisp, Smalltalk, Betamax (versus VHS), FrameMaker (versus MS-Word).

Foote and Yoder came up with the idea of "The Selfish Class" (a reference to The Selfish Gene, by Richard Dawkins) to explain the evolution of software. Would this mean that Mud is more fit for survival than other types of software architectures? Is Mud normal? Is Mud the best we can do in real production systems? Why do people keep doing it? Why do we make money with Mud? In the global software environment, where different architectures fight and compete for survival, it would seem that the Big Ball of Mud is the dominant species.

Does Mud == Legacy? Not necessarily, Mud is produced daily in prodigious amounts. On the other hand, some old code is good (e.g., Smalltalk).

To illustrate his view that mud is the mostly used and deployed software architecture, Foote gave the dark matter analogy.



What are the reasons for Mud happening?

• Throwaway code
• Piecemeal growth
• Keep it working
• Copy / paste metastasis (faulty code is reproduced in many places and spreads)
  

When asked about the best and worst code he has ever seen, Yoder answered the following:

• Best code: the Smalltalk core library
• Worst code: a single C++ class with over 500 000 lines of code. This class is still in production at a large and well-known Silicon Valley company!

Finally, is Agile useful in preventing Mud? Over the years since the first software programs, we went through many changes to what should be the "best" process. But still, year after year, decade after decade, we produce gargantuan mountains of nauseous mud. Is Agile the definite "best" process for avoiding mud? Yoder answers that many aspects of Agile actually seem to lead directly to mud:

• Lack of upfront design
• Late changes to the requirements
• Late changes to the architecture
• Piecemeal growth
  

In the end, maybe teams of good people produce good software, while teams of bad people produce bad software. This means that average teams will have some of both (good and bad), thus slowly inching towards mud. Is it that simple? Did we overestimate the importance of the process?

Overall, it was a very interesting session, with excellent speakers.