Big Ball of Mud

What's considered a big ball of mud is relative to some degree. Some may consider the code to be spaghetti like, while others may consider it to be a great piece of art. Nevertheless, there are several software architectures that most would agree is a big ball of mess. Why is this so popular? I think the main reason is because it's the easiest, fastest way to get code out the door. Managers don't usually like to invest time & money in making a product architecturally sound. A less common situation is when a company buys several small companies, and they stitch together their respective software products in hopes that it will provide the ultimate product. Unfortunately, this is extremely vulnerable to code duplication. More often than not, businesses should at least consider taking the hit and starting over.

What I particularly liked about this article is that it highlighted the forces that cause a big ball of mud. Sure we all know and complain that architecture takes a back seat to time-to-market demands. But on the flip-side of the equation, premature architecture can be risky since it might consume unnecessary resources and it can "discourage evolution and experimentation". Given today's economy, businesses are in great need of fast Return-On-Investments (ROIs). As the article mentions, what's the point of making your product architecturally beautiful if it's going to miss the market deadline and kill your business? Whether or not it was good style would be a moot point.

Finally, I'm a big believer in giving developers time to prototype before committing to a new project. This is because developers first need to get their hands dirty in order to obtain the domain experience they need to make good architectural decisions. Notice that the same reasoning applies as to why its important to first prototype a product of the Layers architectural style.