Comment by memracom

12 years 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.

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.