Comments on: Code Reads #12: “Big Ball of Mud”

By: PINT Blog » Blog Archive » Lessons Learned: Think Twice Before Switching Languages

Fri, 11 Jul 2008 18:54:10 +0000

[...] The prior (PHP) version of cdbaby.com may well have been, architecturally speaking, something of a Big Ball of Mud, but there was, no doubt, a lot of domain knowledge and technical problem-solving packed into that [...]

By: Stuart Caie

Stuart Caie — Tue, 02 Oct 2007 07:30:55 +0000

Having seen impossible-to-maintain programs actually die in the field, their authors giving up on them despite continuing interest from outside, I can attest that “it still works” and “having users” do not keep a broken project working.

What part of “having users” enables a developer to add features that the users desperately want, but surpasses the developer’s capabilities to implement? You can’t say “it still works” to something that yes, works, but is laborious and error-prone to add new functionality to it because it regularly requires updating 400 almost-the-same pieces of code with a fix.

Big balls of mud don’t usually arise from competent programmers implementing well-defined requirements with forethought to future maintenance. They tend to come from the opposite: incompetent programmers, ill-defined and changing requirements and/or throw-away designs.

By: Cléo Saulnier

Cléo Saulnier — Mon, 24 Sep 2007 23:02:52 +0000

Here’s my response,

http://my.opera.com/Vorlath/blog/2007/09/23/codereads-big-ball-of-mud

By: Scott Rosenberg’s Wordyard » Blog Archive » Spolsky on Web app development

Wed, 19 Sep 2007 18:03:37 +0000

[...] passage about Web-app development today could even be read as a (partial, qualified) endorsement of Big Ball of Mud: The developers who put a lot of effort into optimizing things and making them tight and fast [...]

By: Will Free

Will Free — Tue, 18 Sep 2007 22:07:49 +0000

I think that the problem the above architectural astronaut faces when the system is put into production, is that new requrements develop in completly different areas than he anticipated, running counter to the design of the system. Such a system may actually be worse off than the system that just was a ball of mud from the beginning, as that at least has a smaller codebase. This is especially the case in projects that try to make room for every possible functionality that they think may be added in the future into the design. This kind of thinking very often lead to failure.

By: Labnotes » Rounded Corners - 150 (OPTIONS)

Labnotes » Rounded Corners - 150 (OPTIONS) — Tue, 18 Sep 2007 06:35:52 +0000

[...] also that. Scott Rosenberg summarizes the Big Ball of Mud architecture: Despite the best efforts of “best practices” advocates and [...]

By: Will Sargent

Will Sargent — Tue, 18 Sep 2007 00:47:41 +0000

You should take a look at The Inevitable Pain of Software Development: it’s a fascinating analysis of praxis.

By: Invisible Inkling » Is your newspaper.com is a big ball of mud?

Invisible Inkling » Is your newspaper.com is a big ball of mud? — Mon, 17 Sep 2007 15:37:18 +0000

[...] Rosenberg (let’s call him a co-founder of Salon.com to get your attention) has a fascinating post up describing a somewhat academic paper about programming that analyzes the ̶… and finds some advantages to it: Foote and Yoder draw a real-world comparison to shantytowns; [...]

By: Scott Rosenberg

Scott Rosenberg — Mon, 17 Sep 2007 04:39:18 +0000

It took me a lot longer to post this one than I’d hoped. So I should point out that a couple of comments already were posted back here when I first said this was going to be the next reading…