How to overcome the anti-pattern “Big Ball of Mud”

Question

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?

Answer 1

I always attributed the term (BBOM) to a code-base in which "everything depends on everything" and it is hard to find the code you want to change, and when you do make a change you end up having to change stuff all over the place to make it work again. You need the whole code-base in order to test a single changed class/file. Uncle Bob calls this the Morning After Syndrome (here under Acyclic Dependencies Principle).

It's pretty much inevitable that a code base will (ahem) devolve into a BBOM in the absence of basic dependency control because it can't be done by developers that see no more than the code they are currently editing.

Answer 2

This might shed some light on the original question.

http://en.wikipedia.org/wiki/Big_ball_of_mud

A big ball of mud is a software system that lacks a perceivable architecture. Although undesirable from an engineering point of view, such systems are common in practice due to business pressures and developer turnover. They have therefore been declared a design anti-pattern.

Answer 3

In my case, one element of my software is falling into this pattern was a "temporary solution", around two years ago, that has constantly had new features added (always with urgency) at the expense of a rewrite.

If it doesn't cause management pain, they have no incentive to change it. "Yes when you get time next month, you can rewrite it, but we just need it to work for this case just now". As soon as the new feature is in, the rewrite is forgotten about.

I have been explaining for two years that it is a poor piece of code (the implication being that there are unseen bugs in it).

Answer 4

The only time I had to deal with a "BBOM" scenario, we basically had to revisit the requirements with the users and infer what we could from the horrendous code. As with all BBOMs, the issue doesn't usually make itself apparent until there's some maintenance/enhancement needed. (No luxury of code review at this shop, the criteria was sadly "does it do what they want?") And the "author" is long gone.

Refactoring wasn't even possible in this case.

Answer 5

The pertinent quote from the wikipedia article that answers yours is:

Programmers in control of a big ball of mud project are strongly encouraged to study it and to understand what it accomplishes, and to use this as a loose basis for a formal set of requirements for a well-designed system that could replace it.

Answer 6

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.