

Big Ball of Mud - noobSemanticist
http://laputan.org/mud/

======
henrik_w
This is a good, readable paper, with clever pictures to illustrate the points.
Many of the ideas in it are well known (especially if you are already familiar
with XP).

I like the fact that the authors recognize that the BIG BALL OF MUD
architecture is successful (in the sense that many working systems have this
architecture – or rather lack of architecture). In the paper, they describe
the BIG BALL OF MUD architecture, and several related patterns on how you end
up there, but also ways to deal with it and how to work towards a better
architecture.

Some of the main reasons for ending up with a BIG BALL OF MUD are simply time
and money constraints. But the authors also do a good job of discussing other
reasons, for example that in the beginning you simply don’t know enough about
the problem domain to be able to come up with a good architecture. This ties
in with the notion of programming as learning and discovering, more than
simply constructing.

Of the seven patterns discussed in the paper, the only one I hadn’t heard
about before was the SHEARING LAYERS (I also had not seen the term BIG BALL OF
MUD before, but the concept of “lack of architecture” is of course familiar to
everybody). I think it’s a good concept, and something I’ll look more
consciously for in the future.

It is also interesting to note that PIECEMEAL GROWTH can be both a cause of a
BIG BALL OF MUD and a solution to it (when coupled with refactoring). KEEP IT
WORKING also an important strategy, in my mind.

When it comes to RECONSTRUCTION – it may be necessary for several reasons, but
there are also many good reasons not to do a re-write from scratch (Joel on
Software has written a good article about that, see
[http://www.joelonsoftware.com/articles/fog0000000069.html](http://www.joelonsoftware.com/articles/fog0000000069.html)
)

In the paper, there are many comparisons to physical buildings and architecure
in the traditional sense (even many of the pictures emphasize this). These
analogies are good to a point, but it is important to remember that in many
ways developing software is NOT like a constructing a building. In particular,
in software there are no physical laws that constrain the structure, so it is
possible to make things a lot more complex, and with a lot more coupling than
in a physical building. Also, when the program is running there is the whole
dynamic behavior (objects created and destroyed, threads interacting with each
other etc), that is not present in buildings.

There are also several pages of useful references at the end (and it is
particularly cool to be able to have a reference to Vitruvius 20 B.C.!)

All in all I think it is a good paper, with many important ideas presented in
an easy to read way.

The above is a comment I wrote in August 2007 (how time flies!) on Scott
Rosenberg's blog (author of Dreaming in Code),
[http://www.wordyard.com/2007/08/07/next-up-in-code-reads-
big...](http://www.wordyard.com/2007/08/07/next-up-in-code-reads-big-ball-of-
mud/#sthash.biVJc9dF.dpuf)

~~~
SapphireSun
I agree with most of your points, but software is constrained by physics.
Bandwidth (disk/network), calculation speed, which processors to allocate
resources, ram. In fact, many software architectural decisions are made
because of these inevitable physical barriers.

Sometimes the barriers are themselves architectural. How do you network
together two computers when there's no simple route for a network cable and
the Wifi is saturated? Where do you put this monster rack?

In real buildings, there are tons of dynamics - it just depends on the
building. You can have commercial shipments, foot traffic, elevators, go
karts, water pipes, and more. The reason we don't think of these is because
buildings are well designed so that these things are managed well. Imagine if
all commercial shipments were made during peak foot traffic and weren't given
access in the back?

In any case, food for thought. :)

~~~
ams6110
_Imagine if all commercial shipments were made during peak foot traffic and
weren 't given access in the back_

This exact scenario happens at my local Starbucks. The little strip mall it's
in is set so far back on the property that there is no room for a delivery
vehicle behind the building. So they get all their deliveries through the
front door, and it usually seems to happen just at the end of lunch hour (the
worst time, as people are getting their after-lunch coffee).

------
dustingetz
From the urbit project:

 _At some point in Martian history, some abject fsck of a Martian code-monkey
must have said:

"Fsck this entire fscking ball of mud. For lo, its defects cannot be
summarized; for they exceed the global supply of bullet points; for they are
as numerous as the fishes in the sea; like the fishes in the sea they fsck,
making more little fscking fishes. For lo, it is fscked, and a big ball of
mud. And there is only one thing to do with it: obliterate the trunk, fire the
developers, and hire a whole new fscking army of Martian code-monkeys to
rewrite the entire fscking thing."

This is such an obvious and essential response to the big ball of mud pattern
that, despite the fact that we know nothing about Mars, we can deduce that it
must have happened on Mars. Probably several times. Probably several hundred.
For each of these attempts but the last, of course, the result was either (a)
abject failure, (b) another big ball of mud, or (c) both.

But the last, by definition, succeeded. This is the crucial inference we can
draw about Mars: since the Martians had 50 million years to try, in the end
they must have succeeded. The result: Martian code, as we know it today. Not
enormous and horrible - tiny and diamond-perfect. Moreover, because it is tiny
and diamond-perfect, it is perfectly stable and never changes or decays. It
neither is a big ball of mud, nor tends to become one. It has achieved its
final, permanent and excellent state._ [1]

    
    
        http://www.urbit.org/
        [1] https://groups.google.com/forum/#!forum/urbit-dev

------
memracom
The most important thing is to recognize that almost any software project will
tend towards Big Ball of Mud as you add features. If you keep aware of this
possibility then you can recognize when it is about to happen and give your
head a shake, do a bit of design thinking, and move things to a proper loosely
coupled architecture. A Big Ball of Mud is not inevitable.

It's also important to recognize that a lot of the hot new frameworks (ones
that were hot when they were introduced) lead you straight to Big Balls of
Mud. Things like J2EE, ASP.NET, Rails, Django, anything PHP. With these
frameworks you really need to do some up front design thinking and figure out
how to integrate multiple single function apps without linking it all together
in a Big Ball of Mud.

Apache Camel helps with anything in the Java world. AMQP message queuing helps
with any language/platform. In general, look at your framework and ask "If I
had to integrate this with something build in Other Framework X then how would
I do it? Build with your favourite framework but rigorously keep your options
open for integration with other stuff and when you see the Big Ball of Mud
rolling in, you can leverage this integration plan even if you only go for
building several single purpose apps in Rails or J2EE or PHP or whatever.

~~~
hkarthik
The limited, but minimally viable materials to build the shanty towns is very
analogous to using RAD frameworks like the ones you mentioned.

I think the real problem is the subjective nature of deciding when an app is
too big and needs to split apart.

------
enduser
One of the great strengths of Lisp is in how much support it gives the
developer in dealing with BBoM architecture. It helps make the ball smaller
(maybe not fewer lines or characters--Lisp identifiers are often long--but
fewer symbols) and easier to change.

The reality of most projects is that they are a rapid iteration of a prototype
patched to the umpteenth degree. When we get off our high horse of
architectural grandiosity we can start looking for tools that support how
things actually happen.

Of course Lisp has issues, but what matters the most (to me) is what makes the
best mud balls in the end.

------
nabla9
FYI: Big Ball of Mud has two meanings. The one author uses and Lisp meaning.

"APL is like a beautiful diamond - flawless, beautifully symmetrical. But you
can't add anything to it. If you try to glue on another diamond, you don't get
a bigger diamond. Lisp is like a ball of mud. Add more and it's still a ball
of mud - it still looks like Lisp." \- unknown

(alternatively Lisp is bean bag because it always returns to its original
shape)

~~~
hcarvalhoalves
I think the author uses the term in the same way as the LISP quote, since he
doesn't propose that we abolish BBoM, but rather manage it, as it solves
practical problems and is a fact of life.

~~~
nabla9
He uses big ball of mud is a software system that lacks a perceivable
architecture.

Lisp BBoM is not lacking architecture. In the Lisp use of the term it means
that you can extend the system incredibly without losing the "Lispiness". It
looks and feels the same after extensions (if those extensions are done
right). In Lisp building complex framework don't suddenly turn your
programming xml-file configuration and annotating for code generators.

~~~
hcarvalhoalves
Wouldn't you agree that what gives LISP unbounded extensibility without
changing it's form is exactly because it lacks an "architecture", the code is
the AST itself?

It's not like McCarthy purposefully architected LISP to be minimal and
immensely flexible, it naturally followed from implementing the simplest thing
possible capable of manipulating lambda calculus; it's extensibility is a
desirable emerging characteristic.

------
acqq
The problems I was often confronted with in work were of this kind:

[http://blogs.msdn.com/b/ricom/archive/2007/02/02/performance...](http://blogs.msdn.com/b/ricom/archive/2007/02/02/performance-
problems-survey.aspx)

"2) The project has far too many layers of abstraction and all that nice
readable code turns out to be worthless crap that never had any hope of
meeting the goals much less being worth maintaining over time."

------
neonscribe
Closely related to Lava Flow:
[http://en.wikipedia.org/wiki/Lava_flow_(programming)](http://en.wikipedia.org/wiki/Lava_flow_\(programming\))

------
hobs
So sad, but so true. I am living in the big ball of mud, and the bit about the
shanty towns is exactly what I see every day. ;-;

------
smoyer
I read this every few years ... it's well worth keeping these warnings in the
front of your mind!

