Flutterby™! : Big Ball of Mud

Big Ball of Mud

2002-02-25 23:41:22+00 by Dan Lyke 17 comments

Dan D. strongly recommends Big Ball of Mud, a paper on software engineering. From the intro:

This paper examines this most frequently deployed of software architectures: the BIG BALL OF MUD. A BIG BALL OF MUD is a casually, even haphazardly, structured system. Its organization, if one can call it that, is dictated more by expediency than design. Yet, its enduring popularity cannot merely be indicative of a general disregard for architecture.

[ related topics: Software Engineering ]

comments in ascending chronological order (reverse):

#Comment made: 2002-02-26 12:54:11+00 by: meuon [edit history]

Wow.. my 'style' of code writing / project development has a NAME! wow..

"throwaway code that takes on a life of it's own.." it almost defines QDEBIT!

and my use of perl is a 'shantytown': "built from common, inexpensive materials and simple tools. Shantytowns can be built using relatively unskilled labor."

Does this make me legit and not a wannabe?

Lastest lump of mud stuck onto the 'big ball': http://www.downloadalife.com/s...mode=level2&cat1=famous&cat2=all

You could be Bill Gates.. or Linus!

#Comment made: 2002-02-26 13:58:25+00 by: glaser76

The article is a humbling reminder of how far I've fallen. Two years ago I switched jobs from a big, heavily structured and ISO-certified software group with lots of reviews and testing to a tiny, unstructured software company where I produce balls of mud continuously. I'm praised for completing things quickly but no one inspects my code (unless they need to fix a bug when I'm on vacation, and then they're screwed). It's a lot more fun to make mud, really, but I shudder to think what'll happen to my code after I die. (Do any developers make arrangements for posthumous care of their code? That should be standard in any coder's will & testament.) I'd love to have the time to consolidate and re-engineer my code, but there're always more urgent priorities ...

#Comment made: 2002-02-26 13:58:42+00 by: glaser76 [edit history]

(Rats ... double-posted like a dummy ... delete this comment?)

#Comment made: 2002-02-26 15:53:25+00 by: Shawn

Sometimes I wonder if this isn't the reason I'm not making $85,000/year today. Coding balls of mud gives me hives. That's not to say I haven't done it, but I resist the pressure from management to do so. I'm a slow, methodical coder - but I believe that my code is generally more stable the first time around (than, say, a project lead I had a few years back who would scrap and rewrite pages and pages of code two or three times a day until he hit on the right formula). I usually get praise from other programmers for my code, but scowls from management at the time I take to complete it.

#Comment made: 2002-02-26 17:40:55+00 by: Dan Lyke

The more I learn about architecture, the more I like the software engineering as architecture metaphor:

Don't overestimate your useful life. New developments nowadays go up knowing that in 20 or 30 years they're going to be slums. And when those few decades are done, you raze the townhouses, or demolish the office building, and start over. Yes, there are a few things built to last centuries, a few big bridges, but those projects are very few and very far between.
Refactoring, not maintenance. Yes, it'd be nice to have hatches to get into the plumbing in the bathroom, but by the time those parts fail it's a good excuse to tear out the walls and rebuild it in a way that evolves to the user's real needs. Remodeling helps keep the house relevant, and people want a house that will grow and adapt to them.
Architects plan everything out because they have to. One thing that reading A Pattern Language drove home is that architects and builders love malleable building systems. Why, then, do programmers aspire to fixed ones?
Start with the needs of the users and the site. I've seen too many software projects where, metaphorically, the software architect said "we're going to use prestressed concrete", ignoring the fact that the problem is better solved with a suspension bridge. Don't fall in love with a software engineering paradigm, or a language, or a platform. Fall in love with the problem, then pick the right way to approach the problem. If your architect is a specialist, you've got problems.

Ages ago I discovered that often the first thing I had to do when trying to maintain old code was to rip out all the comments. My experience has been that what people write as maintainable code generally isn't anyway, so we may as well concentrate on shipping code, and think instead about ways that we can build the neighborhoods so that we can tear out and rebuild a block here or there.

#Comment made: 2002-02-26 22:53:44+00 by: Shawn [edit history]

Excellent points all, Dan. For the record, I don't write code that I expect to last 20 years (or even 5, or even one). I write code that - hopefully - won't have to be gutted or fixed in the next month or three ;-)

As for maintenance, I like to think I write pretty easily maintainable code. If for no other reason than I tend to comment the heck out of *everything* (which may be one reason that I code more slowly than others). IME, comments are the first thing to be sacrificed in the name of a deadline - only to come back and bite somebody later when they have to spend a day tracing through the code to figure out why/where something is going wonky - or ripping it all out to start over.

I would say that maintainable code is a very attainable goal, provided it comes with adequate documentation. You might not have to rip out so much if you had a clear picture of how it was all intended to fit/work together in the first place.

Edit: Sorry, the first time I read your post, I thought you said "rip out the components". Why do you find it necessary - or even useful - to rip out the comments?

#Comment made: 2002-02-26 23:08:58+00 by: Larry Burton

I would love to have the luxury of maintaining code by completely rewriting the sections that are being changed. The code I write operates equipment, though, and way too many times I'm told about one little change that needs to be made without shutting down the process. Talk about mudballs, I've pleaded with project managers to completely change processors so I would have to rewrite the entire program rather than attempt to make changes to the system that I've been left with.

#Comment made: 2002-02-26 23:45:19+00 by: Dan Lyke

Shawn, my experience has been that comments don't keep up with changes to the code, so by the time I'm in there to do maintenance usually at best they're redundant, but more likely they're misleading. I've been diverted often enough that I now figure it's a net gain to rip out the comments and work backward from the code. Sometimes there's meta-level documentation talking about higher level design, but even then that's usually been subverted by other channels of communication, people who slapped stuff in globals or took advantage of some tertiary state because it was easier than redesigning an interface. Maybe I'm code-cynical, but if it isn't necessary for execution, it's most likely suffered bit-rot.

Larry, I don't envy you, even though I'm hanging out with people who don't always get that the 'net from any given place has far more down-time than a restart on a web server will affect.

#Comment made: 2002-02-27 05:20:34+00 by: meuon

My best comment in code is: #here dummy

And I know Dan, Eric and others have found this in my code and screamed.

On the other hand.. my mudballs are working, making money for their owners years longer then short lived products like 'Windows 3.1' :)

#Comment made: 2002-02-27 06:15:16+00 by: Dan Lyke

The latest one to bite me: I built a table, didn't know yet what the values were, and as things happen forgot about it 'til someone else said "Hey, what's with the 'hell if I know'?"

Sure 'nuff, I'd populated the table with

> struct mapstringtonum_s mapstringtonum[] = {
>   { "HELLIFIKNOW", 0 },
>   { "WHATGOESHERE", 1 },
>   { NULL, 0 } };

Don't think they're gonna let me forget that for a few weeks...

#Comment made: 2002-02-27 17:27:08+00 by: Mars Saxman

Dan, I like the four points you make, but I'm uncomfortable with your last paragraph. Yes, "shipping is a feature", but it still makes sense to design clean architectures and document your code. "Maintenance" isn't something you do after the code ships and you need to upgrade it - it's something you do during development, when you've gone off to some other module for a month, lost all your state, and come back to finish up the first module. Now you have to recall what it was the code was supposed to do and how it expected to do it, and all that work you put in making sure it would last for a few years suddenly pays off.

Maybe we're thinking about different things. You seem to be advocating flexibility and adaptation over blueprints and hierarchies. I don't think they're incompatible. On the project I've been developing for the past nine or ten months, I've been writing the most carefully designed, comment-laden, future-proof code I've ever produced - and it's saved me so much debugging time that I *could* rewrite modules from scratch if I needed to.

-Mars

#Comment made: 2002-02-27 17:48:57+00 by: Dan Lyke

I guess my experience, especially my recent experience, has been that when a system is designed from the ground up rather than grown and adapted with a "ship early, ship often" attitude that the system tends to get far more crufty as people try to fit necessary enhancements and features within the designed hierarchy. I do know a few people competent to produce flexible blueprints, but my experience is that those people are some extremely small fraction of those who think that they're so qualified, and that those people design with maintenance and shipping as the priority.

In fact, I think that this is some of the genius of Microsoft: Features over bug fixes, and if their product histories are any indication, ship version one, then do the design based on the flaws of that product. It's that whole "build one to throw away, you're going to anyway" attitude.

#Comment made: 2002-02-27 18:43:37+00 by: TC

Gawd, I'm sorry I came late into this thread. umm my years have taught me there are 2 basic philosophical camps. Order which allows manageability and maintainability and Chaos which allows for speed and creativity. I think both are valid and sometimes work well in concert. Larger projects require more Order and standards enforment but with a group of high caliber programmers divide and conquer seems to work pretty well too. With most of the stuff I have been doing lately "ship early & often" makes a lot of sense because as you temper code it becomes more robust than most perfectly planned one ship code.

#Comment made: 2002-02-27 20:12:49+00 by: TheSHAD0W

/* And now the magic happens... */

#Comment made: 2002-02-27 20:59:07+00 by: Dan Lyke

/* initialize the counter */
counter = 0;

#Comment made: 2002-02-27 22:46:52+00 by: Shawn

// luser safety net

#Comment made: 2002-03-05 19:15:41+00 by: Dan Lyke

Another realization: Software engineering as architecture has a lot to do with aesthetics. I like fairly spare, functional buildings that fit into the surroundings, but often are overly site-specific (like, perhaps, the old Union Carbide headquarters building in Danbury, or, of course, the Skywalker Ranch buildings). It seems that often colleagues like baroque buildings with filligrees and gargoyles, like religious buildings, which can sit anywhere but really are the sole focus of attention, or pseudo-retro constructions which rely on resurrecting old techniques and technologies, like the Pixar Emeryville campus, which have lots of quirks and tweaks and accomodations the humans have to make to limit them (ie: the cracking floors in the foyer, the cramp in useful space from the diagonals). .