Big ball of mud

It’s no longer the 1960s, it’s 1997, and we’ve been making software long enough that the things we’re building are quite a bit bigger and more complex than the examples Conway had to think about in his paper. And maybe more importantly: we’ve been doing this long enough that systems are starting to get old and smart people, like Brian Foote and Joe Yoder, are starting to notice patterns. 

Patterns, when we talk about software architecture patterns or design patterns, are common shapes that things take to solve common problems. A lot of this comes from Christopher Alexander, who identified patterns in the built environment that included things like “A place to wait.” That place could be a bus stop or a dentist’s waiting room, those different places represent the same pattern. Similarly, in design or software, patterns can be used in any implementation, they are common “shapes” that solutions take.

Architectural patterns in software were something the field had been talking about for a while, and Foote and Yoder’s boss had written a big deal in 1994, Design Patterns: Elements of Reusable Object-Oriented Software that’s full of nice patterns like “bridges” and “facades” which you might use as metaphorical structures for your code.

But Foote and Yoder are looking at what they see actually being built, and they say, this is very nice, and it’s good to have a place to aim for, but these are not the patterns that people are actually using. They argue the pattern that most of us use is one that never comes up, the mess that they call “The big ball of mud.” (Foote & Yoder, 1999)

A big ball of mud is the default architecture groups of humans build, just like bees build hives. Any instance where we have done something else is a triumph of vision and perseverance. Why? Big Balls of Mud don’t just happen because nobody cares about architecture (though that is true also, nobody does.) Nobody thinks they’re good, but they happen anyway.  Why do they happen, despite everybody knowing it’s not the best way? 

Programmers lay the fault of big balls of mud squarely at the feet of management. If management didn’t reorg so often, this wouldn’t happen. “If management would let us do a good job, we’d do a good job.” I hear this from IAs, too, sometimes, and I’m not convinced. There’s something else going on here.

See, a lot of the digital world has actually had a way longer life than most people realize. As Casey Muratori points out in his great video on Conway’s Law, the original code branch of Microsoft Windows has been going since 1985. (Muratori, 2022) You can see it, when you look at even Windows 1.0. Lots of the basic architectural metaphors and ideas are there already. They’re older than I am. There’s lots of old code and architecture out there in a way that I think was hard to imagine in the 1960s.

In early computing, I think they imagined remaking structure and software more frequently than we do. Like Freeman pointed out, content (what you’re trying to do) should dictate form (the structures you use to do it.) But it’s much easier to add a little something on, change something just enough, than to throw everything out and start over. Especially if you don’t realize you need to. Foote and Yoder say, “There is nothing more permanent than a temporary solution that works.” Lots of things can be made to work, so you get little bits added on over time. 

Inheriting a structure is the norm, very few of us will work on something completely new. Because people reproduce their social structures in the structures they build, those things we inherit will have the old structures, but they’ll also have the new ones, as people drift around. Both of those structures will be mishmashed together. The only time this stops happening is if you throw everything out and start over.

I’m not sure it’s possible to understand how Microsoft Teams works without understanding how it grew out of the Sharepoint team. Windows has five different volume controllers because five different versions of Windows have all added their own volume controllers. Libraries still struggle to handle periodicals and books equivalently (if they even should) because those information and social structures diverged back in Babylon. All complex human structures have these geologic layers of human relationships fossilized in them. It can be hard to tell, because they’re so tangled in each other. 

This is why I think it’s too simple to just say “oh, management won’t let us do a good job.” There are other impacts that they talk about in the article, but this is how we get mess. The inevitable combination of human relationships and time. 

I like thinking about it his way because relationships and time are what creates information architecture as such, I think. Because humans have structure, information does, too. That doesn’t mean that information arranged by one person by themselves can’t have architecture, it frequently does, but it’s not practically consequential. I think of it like having good manners when you’re alone. Maybe it’s nice or a good habit, but it doesn’t matter too much, since there’s no one there to appreciate it or be disgusted by you. No communication is happening. 

IA primarily matters when information is going to be used between people or across time (the relationship between you and future you). And those same relationships between people and time are what inevitably create mess.

If you’re reading this, I strongly suspect you’ve already been indoctrinated into the anti-big ball of mud camp. They shouldn’t exist! Clean up all the mud!

I would like to speak for the mud for a moment. I’m not going to argue for the benefits of mud yet, though we’ll get to that, but I want to encourage you to get comfortable with it. 

Mess is where we live. Stouman and Falk wrote in 1936 that the  “comparability of statistics has rarely, if ever, been obtained before there was a definite demand for it.” Standardization is hard, generally, things are messy, then there’s a demand for it to get better, and we come in and fix it. 

We can assume that most systems we encounter are the most complicated that can possibly work. (Foote & Yoder, 1999) It takes energy and skill to simplify something, so adding complication is an easy answer. The temporary fixes that become permanent add complication. Balls of mud are complicated. 

Systems also end up being complicated because of a mathematical process known as a random, or drunkard’s walk. Imagine a man standing on a sidewalk. On one side, there is the wall of a building, on the other side, a gutter. With every step he takes, he’ll go forward, but can also stumble either left or right. Left to walk along this sidewalk indefinitely, how often will he end up in the gutter?

He’ll end up in the gutter every time, because the wall effectively prevents him from going further that direction. Similarly, there is a point at which a system truly cannot get simpler, and everything you might add to it will make it more complicated. Given an indefinite lifespan, every system will become complicated, a big ball of mud. 

In a discussion of this paper in 2007, Foote pointed out that despite the paper becoming very famous, despite it being argued about on Slashdot and now on Reddit, no one ever disputes the premise. (Foote, 2007)Developers never argue that actually everything’s fine. There’s something deeply true here.

So, big balls of mud are the standard, and they’re where we work, because we don’t get brought in for no reason. Sometimes these structures get too complicated to work at all, or sometimes the task or context changes too much, and they can’t keep up. So we get a call. This is the horizon where we live as IAs.

References

Foote, B., & Yoder, J. (1999). _ Big Ball of Mud_. Pattern Languages of Program Design 4 . http://www.laputan.org/mud/?ref=coding-horror