8 ms·
Big Ball of Mud (1999)
- dmoy 2y agoNote 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 https://en.m.wikipedia.org/wiki/Dorodango There's gotta be some analogy to the software big ball of mud though
- TremendousJudge 2y agoI can't speak for anybody else, but some days this is what dev work feels like to me.
- josephg 2y agoThose balls look similar to the Google Chrome logo. Total coincidence, I’m sure!
- MatthiasPortzel 2y ago(1999)
- thesuperbigfrog 2y agoThank you. Updated the title.
- 1penny42cents 2y agoWhat's the correlation between code quality and business success?
- Jtsummers 2y agoDepends on the timescale and how captive the audience is. Oracle DB has a reportedly pretty bad codebase but a captive market that keeps them from needing to address the problems (as rapidly as their customers might like). If low quality lets you be first to market, that may be worth the later maintenance costs by gaining an outsized portion of the market and earlier revenue than your competitors. On the other hand, if you've got an old system with poor quality code and can't make changes, your customer(s) are willing to drop you, and you have competitors who can get out the desired features, you're screwed.
- bazoom42 2y agoNobody knows, since there is no agreed-upon way to measure code quality.
- Ma8ee 2y agoI’ve seen companies rapidly collapse because they couldn’t adapt their code base to current platforms or new requirements. As long as nothing changes and you don’t have too many bugs, your code can look like crap under the surface without issues. It’s the day you can’t sell your product without a UI that works on a phone and you have to change every single method to make the change, or you fail to implement the new tax rules correctly even after 18 months of all hands on deck, it matters. Then it doesn’t have be that bad to have business impact. What does your customer say when the new feature that was promised in one month takes eight months to deliver, or your CFO say when it will take 15 years of licensing fees from that customer to pay those 24 man months to get the features working?
- mvdtnz 2y agoThis is bearishly hard to measure. For example (this is a real, recent scenario, left intentionally vague): a new government regulation gives you 12 months to expose certain data conforming to a provided API schema. The system under development is a big ball of mud. Re-shaping the data to conform to this schema turns out to be extremely difficult but failing to produce the APIs on time will result in company-endangering penalties from a government regulator with no sense of humour. So you put a team on the APIs and issues keep cropping up again and again because every time one thing is changed it has knock-on effects causing other company-endangering incidents because you're making changes to to way billing and invoicing data is presented, or to how incoming metering data is stored. So you put some additional teams on the project and work everyone to the bone. Some senior developers burn out and leave the organisation. Likewise some project managers. Your best QA staff have their morale drop to rock bottom. The project delivers on time but how do you measure these costs? How are you going to put a dollar figure on the burnout and lost staff? How much of the senior developers' decisions to leave can be attributed to the project and the big ball of mud? How do you measure the impact of your best tester losing his will to work and going dark? Many of us have worked in organisations where things have gone down like this. We all know that impact is huge. But yeah you're right, I can't put together a business case that says it in clear numbers. On paper we had a one-year project, it probably went a bit over budget but it ultimately delivered so what's the big deal about the big ball of mud? Except that our competitors were able to produce the same APIs for a fraction of the cost without burning out half their staff.
- marcosdumay 2y agoI doubt you can correlate to a line. But it may track a down-facing arc.
- Jtsummers 2y agoStolen from dang [0] on the last submission with that submission added in: Big Ball of Mud (1999) - https://news.ycombinator.com/item?id=35481309 https://news.ycombinator.com/item?id=35481309 - Apr 2023 (32 comments) Big Ball of Mud (1999) - https://news.ycombinator.com/item?id=28915865 https://news.ycombinator.com/item?id=28915865 - Oct 2021 (23 comments) Big Ball of Mud (1999) - https://news.ycombinator.com/item?id=22365496 https://news.ycombinator.com/item?id=22365496 - Feb 2020 (48 comments) Big Ball of Mud - https://news.ycombinator.com/item?id=21650011 https://news.ycombinator.com/item?id=21650011 - Nov 2019 (1 comment) Big Ball of Mud (1999) - https://news.ycombinator.com/item?id=21484045 https://news.ycombinator.com/item?id=21484045 - Nov 2019 (1 comment) Big Ball of Mud (1999) - https://news.ycombinator.com/item?id=13716667 https://news.ycombinator.com/item?id=13716667 - Feb 2017 (6 comments) Big Ball of Mud (1999) - https://news.ycombinator.com/item?id=9989424 https://news.ycombinator.com/item?id=9989424 - Aug 2015 (9 comments) Big Ball of Mud - https://news.ycombinator.com/item?id=6745991 https://news.ycombinator.com/item?id=6745991 - Nov 2013 (21 comments) Big Ball of Mud - https://news.ycombinator.com/item?id=911445 https://news.ycombinator.com/item?id=911445 - Oct 2009 (2 comments) The "Big Ball of Mud" Pattern - https://news.ycombinator.com/item?id=10259 https://news.ycombinator.com/item?id=10259 - April 2007 (2 comments) [0] https://news.ycombinator.com/item?id=35484495 https://news.ycombinator.com/item?id=35484495
- sillysaurusx 2y agoSometimes 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.
- nyrikki 2y agoTechnically a huge switch statement isn't a ball of mud. It is mutually exclusive and completely exhaustive. It may have other issues, but is actually better than what this article is describing.
- sillysaurusx 2y agoI happen to agree, but only in this special case. Normally a giant switch statement is a pain to work through if there's even a tiny amount of logic involved. One hilarious case was at Scottrade. I was poking around their C++ codebase one day and to my amazed horror saw a file hundreds of lines long, and a big chunk of it was devoted to handling leap years. Like, every leap year, one at a time. There are few enough leap years that it should in theory be difficult to write hundreds of lines of code to handle each of them, but some contractor managed to. And so the ball of mud continued. What can you do but laugh and embrace the horror?
- throwway120385 2y agoAt least you can be sure that it worked, whereas if he'd actually written the succinct version there was a risk of a subtle bug.
- free_bip 2y agoThe 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.
- pylua 2y agoI feel like this is typically not the right choice.
- bazoom42 2y agoHow did you measure the 3x factor?
- free_bip 2y agoMostly by looking at how long simple changes (e.g. changing a fee + fee message at checkout) that should only take a day or less, actually take.
- bazoom42 2y agoBut how do you know how long a change “should” take? And how do you know if the rewritten code would be any easier to change? I tend to be sceptical of “rewrite everyting” projects since they are often based on wishful thinking.
- butlike 2y agoAlice has arthritis, so it takes her 3min longer to write any functional changes. She, however, has domain experience across the entire application. Bob can write code 2min quicker than Alice, but is relegated to a specific section of the codebase.
- jmull 2y agoHmmm... considering that your current codebase became a Big Ball of Mud, is there any reason to think the same won't happen to your next codebase? Not that I'm saying don't rewrite. It will certainly be more fun and likely good for the resume.
- hitchstory 2y agoI 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.
- gedy 2y agoThe article calls these folks "swamp guides"
- worstspotgain 2y ago> a mixture between a crossword puzzle and archaeology Cue cave escape scene chased by huge rolling boulder.
- seabrookmx 2y agoI really think that archaeology you speak of is great for building skills, and as a result when giving the opportunity you start building much more elegant solutions. My career path has followed a similar trajectory but I do enjoy a good "mud wrestle" as you call it every now and then :)
- eitally 2y agoGenerally speaking, mud wrestling jobs exist in traditional IT departments, not tech product companies, and the jobs pay far less than those where the code is the product. For better or for worse, but the existence of "big balls of mud" is largely a result of "you get what you pay for" mentalities in non-technical CIOs & CTOs... or industries where IT spend is below some low threshold (e.g. 1% revenue).
- antimora 2y agoI 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.
- mckn1ght 2y agoThis one and https://www.mindprod.com/jgloss/unmain.html https://www.mindprod.com/jgloss/unmain.html should be required reading for all new programmers. Although sadly they can’t really appreciate them until actually subjected to them.
- jallmann 2y agoFeels like there is a similarity in a big ball of software mud and complaining about the layout of a website. Does it do the job? Yes? Cool, moving on.
- dakiol 2y agoAren’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.
- kown7 2y agoIf it were that easy, why do most systems converge to The Big Ball of Mud?
- AnimalMuppet 2y agoRelated: 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!
- klyrs 2y agoI put a UML diagram generator in there somewhere, you just need to run it to get the docs up to date. It's been a while though... but I remember that the name was a really good pun. Good luck!
- marcosdumay 2y agoThe ravioli architecture. It's not spaghetti!
- aidenn0 2y agoIs 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
- rurban 2y agoI can also recommend the whole book "AntiPatterns", with many more such Anti-patterns. http://antipatterns.com/thebook.htm http://antipatterns.com/thebook.htm
- delichon 2y agoTake 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.m570.l1313&_nkw=septarian&_sacat=0 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.
- bozhark 2y agoWho links images you have to login to view?
- marcosdumay 2y agoI can view without an account. It may be region-specific (or ad-blocker specific).
- trhway 2y agoI'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.
- deleted 2y ago[deleted]
- alexpotato 2y agoI 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).
- geekone 2y agoYeah that's pretty much how I've observed this happening, though I've found this scenario to be so much more common in teams that are overloaded with competing priorities they have no control of because of (usually) poor and/or naive management. To the point where even at 5-8 occurrences you kick the proverbial can down the road to focus on the "important" work items.
- whstl 2y agoAt my last job we had a few bash scripts like those. They could have used a bash loop, but one of the developers wasn’t good with Bash, so he took to himself to rewrite using a handmade javascript framework. It was quite complete and very smart, with lots of OOP patterns and wrappers abound. But it was not only impossible to understand, it was almost impossible to debug too, because of the amount of indirection. Big balls of mud often also appear because people actually say “hey maybe we should…” but but still manage to miss the mark. As much as I would love to give some insightful comment here, I can’t. To paraphrase a post I saw here about Casey Muratori: sometimes the only advice you can give to someone is to “get good”. Putting in the 10000 hours and getting actual feedback rather than pretending that the bullshit you wrote is good because the previous one was understandable by a non-techie.
- 2y ago
- x-complexity 2y agoMy 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.
- ggm 2y agoIn 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.
- jt2190 2y ago> 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.
- foobarkey 2y agoNo 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
- marcosdumay 2y agoIt's the same Big Ball of Mud architecture. It's just implemented over YAML (what a great programming language!) and has crunchy microservices inside! (I'm not sure I want to know what the crunchy bits in a ball of mud are).
- mckn1ght 2y agoWell, as a BBoM rolls on down through a village, it tends to accumulate various trinkets and detritus from smashed buildings, along with the broken bones and teeth of the people it obliterates, along with their pets and livestock, and any nearby wild fauna.
- patterns 2y agoI 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/ https://feenk.com/ [2] https://gtoolkit.com/ https://gtoolkit.com/ [3] http://www.bitsavers.org/pdf/xerox/parc/techReports/CSL-81-3_An_Experimental_Description-Based_Programming_Environment.pdf http://www.bitsavers.org/pdf/xerox/parc/techReports/CSL-81-3...
- reverseblade2 2y agoFun 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