Menu
What causes a computer program to turn into a Big Ball of Mud? Is it possible to recover from this anti-pattern? Are there proven refactoring methods that can be applied?
748
By creating smaller modules that limit their coupling can help prevent a big ball of mud. You may end up with smaller balls of mud, but that's much easier to tackle and comprehend in a large system.
A big ball of mud is a software system that lacks a perceivable architecture. Although undesirable from a software engineering point of view, such systems are common in practice due to business pressures, developer turnover and code entropy. They are a type of design anti-pattern.
"A Big Ball of Mud is a haphazardly structured, sprawling, sloppy, duct-tape-and-baling-wire, spaghetti-code jungle. These systems show unmistakable signs of unregulated growth, and repeated, expedient repair.
In an organization, there are three main opportunities to identify anti-patterns: During design reviews, during code reviews and during refactoring of legacy code. Design reviews are a great opportunity to find anti-patterns.
A Big Ball Of Mud normally occurs because of one of the following:
Change of Requirements - You architect a solution with one set of requirements, which over time change and now, you are probably catering to a different audience who wants to use the same product with slightly different requirements. You bake those requirements into the same product and you end up with a BBOM.
Change of Developers - The original product has been created by one set of developers with certain design and architectural assumptions which are not entirely evident to a whole new set of developers who 'take over' the product for maintainence or further development. The new developers make their own assumptions and over time, the product degrades into a pile of unmaintainable junk.
Incompetency - of the developers (they are unaware of anti-patterns), the management (too demanding, lack of knowledge of the product) or the users (they don't really know what they need). This is hard to solve.
Sometimes, the best solution is simply to rewrite the application catering to the new requirements. But this is normally the worst case scenario. The cumbersome solution is to stop all new development, start by writing a set of tests and then redesign and rearchitect the whole solution. This could take years, depending on the size of the product, though.
68
BBOMs I have encountered were usually created organically, in a Darwinian process. It goes something like this:
Initally, a system is created (not designed) and poorly documented.
Original resources go on to create more havok elsewhere, so there isn't even an oral history for this "legacy" system.
Fresh blood is brought in. These developers try to uncover workings of various system parts, but it's like several blind men trying to understand the elephant when one has grabbed the tail, one a leg, and one the trunk. They make changes but never really feel confident about them.
In this way, a system "evolves" by blind natural selection, but parallel to this is an evolution of the most intractable, unreproducible bugs that persist precisely because they remain under the radar screen, until of course they surface at a customer installation.
25
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
