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)
- 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!
- Lack of upfront design
- Late changes to the requirements
- Late changes to the architecture
- Piecemeal growth
Overall, it was a very interesting session, with excellent speakers.
I put it to you that a system with 500,000 lines of code, that is still working, is an achievement not to be dismissed.ReplyDelete
The fact that it was written in one class shows there are many ways to skin a cat. It doesn't prove it is a bad design. Modularity can be organised in other ways than by division into OO classes.
Yes, this is our point. Though it is interesting to note that the organization that has that class doesn't want to touch it as they are afraid it might break and they are considering ways to refactor it. They claim it as a BBoM not me!ReplyDelete
Part of our story is that a BBoM can happen and still provide usefulness. Our main claim is that it is a reality and should be understood and accepted more rather than ignored...Joe Yoder