Big Ball of Mud (1999)

Sometimes a big ball of mud is exactly what’s needed.

Undertale has a single giant switch statement thousands of cases long for every line of dialog in the game. There are other stories of how infamously bad the code is. And none of that mattered one bit.

Banks are another example. The software is horrible. Everyone knows it. Yet all that’s required is minimally working software that fails rarely enough that the bank can maintain their lock in.

Believe it or not, being hired to work on a big ball of mud can be pretty chill. The key is for you to be in a stage in your life where you don’t really care about your work beyond meeting professional responsibilities. Big ball of mud codebases are the best for that, because everyone’s there for the same reasons, and the assignments are always easy drudgery. Neither Scottrade nor Thomson Reuters cared too much what I was up to as long as I was there at 9am.

It’s soul crushing for people who want to create nice things, or seek meaning in their work, which is partly why I left. But when you just need the money, there’s no substitute.

Stolen from dang [0] on the last submission with that submission added in:

Big Ball of Mud (1999) - https://news.ycombinator.com/item?id=35481309 - Apr 2023 (32 comments)

Big Ball of Mud (1999) - https://news.ycombinator.com/item?id=28915865 - Oct 2021 (23 comments)

Big Ball of Mud (1999) - https://news.ycombinator.com/item?id=22365496 - Feb 2020 (48 comments)

Big Ball of Mud - https://news.ycombinator.com/item?id=21650011 - Nov 2019 (1 comment)

Big Ball of Mud (1999) - https://news.ycombinator.com/item?id=21484045 - Nov 2019 (1 comment)

Big Ball of Mud (1999) - https://news.ycombinator.com/item?id=13716667 - Feb 2017 (6 comments)

Big Ball of Mud (1999) - https://news.ycombinator.com/item?id=9989424 - Aug 2015 (9 comments)

Big Ball of Mud - https://news.ycombinator.com/item?id=6745991 - Nov 2013 (21 comments)

Big Ball of Mud - https://news.ycombinator.com/item?id=911445 - Oct 2009 (2 comments)

The "Big Ball of Mud" Pattern - https://news.ycombinator.com/item?id=10259 - April 2007 (2 comments)

[0] https://news.ycombinator.com/item?id=35484495

I used to be really good at working with big balls of mud.

I actually even started enjoying it at some point - it felt like a mixture between a crossword puzzle and archaeology. There was also something nice about being good at something other people hated that was nonetheless very critical.

Somewhat ironically though, the better I got at it, the class of job I got the better the quality of the code I ended up working with.

Now my mud wrestling skills have atrophied a fair bit.

I worked at a firm once that had a cronjob that restarted 70+ instances of the same component.

The line was essentially a collection of:

  restart instance_N &; restart instance_N+1&; 

etc

I always assumed that the way you got to 70+ was:

- write the first restart for instance N=1

- add another restart

- keep doing this till you get to about 5-8 restart commands

- AT THIS POINT someone should say "Hey, we should make this a script or something else" BUT CRUCIALLY that didn't happen

- you keep adding restarts till you get to 20+

- Now, doing anything to that giant line other than adding a new restart feels too dangerous so you decide to just keep adding restarts.

Moral of the story: the ball of mud usually doesn't just appear out of nowhere. It appears b/c there were multiple steps were someone didn't say "hey, maybe we should..." (or they said it and no one listened).

Note this is not about the art form that is essentially polishing a big ball of mud into a shiny colorful ball (of mud)

https://en.m.wikipedia.org/wiki/Dorodango

There's gotta be some analogy to the software big ball of mud though

No worries, we have since moved on and people who cant write more than 2000 coherent lines of code have invented a new solution called microservices. Now you can have very simple services that don’t turn into a mess!

Well that’s the idea anyway, but it always turns into a mess and then I have been using a new term to describe it: spaghetti over http

I often forward this article to my fresh software engineers but they often get put off by the layout. So I tell them beforehand not to pay too much attention to it =)

P.S. I love it and still re-read it sometimes.

Take a ball of mud, apply pressure and time, and you sometimes get a septarian concretion. They can be quite beautiful, I have a pair of bookends cut from one on my shelf.

https://www.ebay.com/sch/i.html?_from=R40&_trksid=p4432023.m...

I've seen some big balls of software mud that formed very nicely under pressure too.

Is the guy in that first picture John Lennon?

[edit]

After doing the obvious thing and googling "john lennon shovel waiter" it is indeed him from Magical Mystery Tour

I have been pondering about this issue for a while. Maybe it is inevitable that successful systems turn into big balls of mud eventually once the "inflection" point has been reached and (slow) deterioration begins.

It is somewhat of a clichè but I think that (interactive) documentation and tooling can make a difference, but it is very difficult to design the process and the tooling to be as frictionless as possible. Tudor Girba and his team at feenk have been doing a lot of interesting work in that area that's worth a look [1, 2].

The software in question might be an entangled mess, a large part of it might be even inherent due to its requirements or technical constraints, but if that messy web can be readily augmented with background information and sign-posts I think the situation could be significantly improved.

On a related note, there has been a project at Xerox PARC called PIE (Personal Information Environment) [3] which has put forward the idea of organizing software and its artifacts (source code, various kinds of documentation) as a network. Although that particular concept has never been adopted in any major programming system as far as I know, I think that it has huge potential, especially if the software, as a network, can be collaboratively navigated and extended with additional information, where and when needed -- online.

Now that all does not change the fact that we are still dealing with a ball (or a web) of mud, but at least it is accessible and we might have a better chance to understand its evolution and the reasons that made it complicated in the first place.

[1] https://feenk.com/

[2] https://gtoolkit.com/

[3] http://www.bitsavers.org/pdf/xerox/parc/techReports/CSL-81-3...

I can also recommend the whole book "AntiPatterns", with many more such Anti-patterns. http://antipatterns.com/thebook.htm

What's the correlation between code quality and business success?

My personal opinion about the Big Ball of Mud is that it lacks the visual component makes problems immediately apparent: No one dares to enter a building with a big visible crack along one of its edges, but if such a thing existed in software, management would just tell the team to power through it.

The moment that someone manages to crack the software visualization problem for the layperson, would be the (moment + delay) that considerable effort would actually be invested in software architecture.

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

> These patterns [BIG BALL OF MUD, THROWAWAY CODE, PIECEMEAL GROWTH, KEEP IT WORKING, SHEARING LAYERS, SWEEPING IT UNDER THE RUG, RECONSTRUCTION] explore the forces that encourage the emergence of a BIG BALL OF MUD, and the undeniable effectiveness of this approach to software architecture. What are the people who build them doing right? If more high-minded architectural approaches are to compete, we must understand what the forces that lead to a BIG BALL OF MUD are, and examine alternative ways to resolve them.

In the 80s I wrote a Transport Layer as a computed GOTO via a PL/1 language feature, basically it was a finite state machine.

I think a lot of problems which reduce down to this are done by function-table lookups (as in, look up in a table the index of the next state, and call the function) but for the language I had, that wasn't an option.

The codebase I work on is a Big Ball of Mud. It takes roughly 3x the effort to make any functional changes due to this (and thus we have 3x the devs we actually need). When it was framed like that, the business was eager to start a total rewrite project.

Aren’t we paid the big money precisely to handle Big Balls of Mud? If everything were pristine, easy to read, easy to extend, etc., then anyone could do it, for a cheap price.

Related: Big mound of pebbles. Instead of a pile of a million lines of code with no structure, it's a pile of 10,000 classes. But hey, it's got some out-of-date UML diagrams in a 1990s CASE tool that "explain" the architecture!

I'd have liked more mathematical treatment. Can the ball of mud be modeled as a some kind of an attractor or a result of backpropagation style optimization inside the organizational chaos and multitude of conflicting priorities, resource constraints, etc.

Fun fact, when I told my skip level manager that we have is big ball of mud, I think he was unfamiliar with the term.

Few months later I heard a complaint from my direct manager that I called our code “big ball of crap” and it was a major software company

(1999)