8 ms·

Big Ball of Mud

hobs 13y ago
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. ;-;
nabla9 13y ago
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 13y ago
  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 13y ago
    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 13y ago
      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.
- hga 13y ago
  Joel Moses, the father of Macsyma, is the author of this quote.
acqq 13y ago
The problems I was often confronted with in work were of this kind: http://blogs.msdn.com/b/ricom/archive/2007/02/02/performance-problems-survey.aspx http://blogs.msdn.com/b/ricom/archive/2007/02/02/performance... "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."
henrik_w 13y ago
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-ball-of-mud/#sthash.biVJc9dF.dpuf http://www.wordyard.com/2007/08/07/next-up-in-code-reads-big...
dustingetz 13y ago
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
losethos 13y ago
The guy talks for 20 pages and says what I could summarize in a sentence. "Unorganized code is unorganized."
smoyer 13y ago
I read this every few years ... it's well worth keeping these warnings in the front of your mind!
neonscribe 13y ago
Closely related to Lava Flow: http://en.wikipedia.org/wiki/Lava_flow_(programming) http://en.wikipedia.org/wiki/Lava_flow_(programming)
enduser 13y ago
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.
memracom 13y ago
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 13y ago
  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.

hobs 13y ago

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. ;-;

nabla9 13y ago

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 13y ago
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 13y ago
  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 13y ago
    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.
hga 13y ago
Joel Moses, the father of Macsyma, is the author of this quote.

acqq 13y ago

The problems I was often confronted with in work were of this kind: http://blogs.msdn.com/b/ricom/archive/2007/02/02/performance-problems-survey.aspx http://blogs.msdn.com/b/ricom/archive/2007/02/02/performance... "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."

henrik_w 13y ago

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-ball-of-mud/#sthash.biVJc9dF.dpuf http://www.wordyard.com/2007/08/07/next-up-in-code-reads-big...

dustingetz 13y ago

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

losethos 13y ago

The guy talks for 20 pages and says what I could summarize in a sentence. "Unorganized code is unorganized."

smoyer 13y ago

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

neonscribe 13y ago

Closely related to Lava Flow: http://en.wikipedia.org/wiki/Lava_flow_(programming) http://en.wikipedia.org/wiki/Lava_flow_(programming)

enduser 13y ago

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.

memracom 13y ago

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 13y ago
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.