I read this every few years ... it's well worth keeping these warnings in the front of your mind!
Big Ball of Mud
11–20 of 23 posts
Re: Big Ball of Mud
#12Closely related to Lava Flow: http://en.wikipedia.org/wiki/Lava_flow_(programming)
Re: Big Ball of Mud
#13FYI: 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 it…
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.
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.
Re: Big Ball of Mud
#14Earlier quoted context omitted.
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.
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 anno…
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.
Re: Big Ball of Mud
#15One 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.
Re: Big Ball of Mud
#16This 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 architectur…
> 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 m…
"shantytowns solve the habitation problem of many people more adequately than if the same people had to wait under the bridge for the market to provide beautifully architected villas at affordable prices."
This must be one of the most braindead sentences I have read in a long time. I dare you to count all the fallacies involved.
Re: Big Ball of Mud
#17The 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.
Re: Big Ball of Mud
#18Earlier quoted context omitted.
> 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 m…
"shantytowns solve the habitation problem of many people more adequately than if the same people had to wait under the bridge for the market to provide beautifully architected villas at affordable prices." This must be one of the most braindead sentences I have read in a long time. I dare you to count all the fallacies involved.
I suggest you try to understand inside the context of the comment, or give up trolling HN.
Re: Big Ball of Mud
#19This 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 architectur…
The text is readable, but the 1999 HTML is awful. The PDF is better (http://laputan.org/pub/foote/mud.pdf) or use Readability or something similar.
Re: Big Ball of Mud
#20This 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 architectur…
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 W…
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).