[HN Gopher] Big Ball of Mud (1999)
___________________________________________________________________
Big Ball of Mud (1999)
Author : thesuperbigfrog
Score : 64 points
Date : 2024-07-10 19:29 UTC (3 hours ago)
(HTM) web link (laputan.org)
(TXT) w3m dump (laputan.org)
| dmoy wrote:
| 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
| TremendousJudge wrote:
| I can't speak for anybody else, but some days this is what dev
| work feels like to me.
| josephg wrote:
| Those balls look similar to the Google Chrome logo. Total
| coincidence, I'm sure!
| MatthiasPortzel wrote:
| (1999)
| thesuperbigfrog wrote:
| Thank you. Updated the title.
| Jtsummers wrote:
| 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
| sillysaurusx wrote:
| 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.
| nyrikki wrote:
| Technically 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 wrote:
| I 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 wrote:
| At 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.
| wewtyflakes wrote:
| Why would such a system assure someone that it worked?
| Conversely, why would only the succinct version lend
| itself to a subtle bug?
| codetrotter wrote:
| Mine is as succinct as they come, but a little bit buggy
| int is_leap_year(int year) { return 0; }
| wewtyflakes wrote:
| I don't think that qualifies as a "subtle" bug. :)
| skybrian wrote:
| You can only be sure if you verified every year and
| didn't miss a typo. Having a test that straightforwardly
| checks every year individually would be more useful,
| since then you know if you changed anything, and can
| double-check just the changes.
|
| Although, I suppose it doesn't matter all that much which
| is which, as long as they're not both written the same
| way.
| worstspotgain wrote:
| Maybe the author wanted to squeeze as many hours out of the
| task as they could? Plenty of non-top-quartile people love
| this sort of thing as a day at the beach.
|
| For the diametrical opposite, here's one time on an
| embedded system where I really didn't want to bring in a
| library dependency, so I wrote an inconspicuous-looking
| good-enough version: y = (d - (d + 366 +
| (d >= 47847)) / 1461 + (d >= 47847)) / 365; d = d -
| (d + 365 + (d >= 47848)) / 1461 + (d >= 47848) - y * 365;
| y += 1970;
| shawndumas wrote:
| #include <iostream>
|
| int main() { long long d; std::cout << "Enter a Julian
| Day Number: "; std::cin >> d; if (d <
| 0) { std::cerr << "Error: Invalid Julian Day
| Number (must be non-negative)." << std::endl;
| return 1; // Indicate an error to the system }
| const int DAYS_PER_YEAR = 365; const int
| DAYS_PER_LEAP_YEAR = 366; const int
| DAYS_PER_LEAP_CYCLE = 1461; // 4 years const int
| JULIAN_TO_GREGORIAN_THRESHOLD = 2299161; // Oct 15, 1582
| // Adjust for Julian-to-Gregorian transition if
| (d >= JULIAN_TO_GREGORIAN_THRESHOLD) { d +=
| 10; // Account for dropped days }
| int a = d + 32044; int b = (4 * a + 3) /
| DAYS_PER_LEAP_CYCLE; int c = (4 * a + 3) %
| DAYS_PER_LEAP_CYCLE; int y = (b / 1460) +
| 1970; d = (c / 4) - 365; if (d < 0)
| { y--; d += DAYS_PER_YEAR + (y %
| 4 == 0); } std::cout << "Gregorian
| Year: " << y << std::endl; std::cout << "Day of
| Year: " << d + 1 << std::endl; // Add 1 as days are
| typically 1-indexed return 0; }
| worstspotgain wrote:
| Not only that, but you can ask it to rewrite it in iambic
| pentameter and with pirate-speak identifiers.
|
| Really begs the question of what the long-term outlook is
| for the non-top-quartile people. Maybe re-prompting LLMs
| is the new ball of mud?
| nyrikki wrote:
| I am not talking about ease of programming, and c being
| imperative, and the explicit break are edge cases.
|
| But for case value
|
| value can only be char or int, and must be unique
|
| Really it is just sugar for if-else-if, but if you enforce
| explicit break in your code it is as close to a provable
| total function as you get in C.
|
| Total functions are the ideal in any code.
|
| As determining whether or not a function F is total is
| undecidable, switch is more reliable than if-else-if
| ladders.
| pixl97 wrote:
| Ooof, I have dealt with some fun balls of mud.
|
| Had a customers app break when they used zips that contained
| over 65k separate files. Sent it to dev and they said "Oh use
| this other API we have". And yes, the file 'worked' but the
| api didn't do what the customer needed. Got back with the
| developer and saw
|
| We had two api's that did almost but not quite the same
| thing. Ok, it happens, maybe there was a reason for it.
|
| We also had two different zip libraries built in. At some
| point a dev ran into issues with legacy zip support not
| working on large files and added a new library. They
| converted about 10% of the API, enough to cover what they
| were working on and stopped.
| osigurdson wrote:
| >> "Oh use this other API we have"
|
| This is an interesting problem. If you insist on maximizing
| consistency on a large code base, then nothing can ever
| change. If you allow too many small deviations / good ideas
| that are only ever partially completed, it results in
| chaos. I think it is a little like entropy: some (not too
| much) is needed for things to progress.
| pixl97 wrote:
| So this was a few years back and they've wrangled a lot
| of the mess in. They've went with API versioning where
| you can set a flag in the request of something like ver=5
| and you get a static version of the api that doesn't
| change. If you don't set an api version you get the
| latest version, which may break on updates.
|
| I think for most users it's made feature observability
| much better.
| Quekid5 wrote:
| Turing Machines have that property. There the Tarpit lies.
| ChrisMarshallNY wrote:
| One of my first programming gigs was working on a
| 1970s-vintage, 100KLoC+ FORTRAN IV codebase.
|
| All one file.
|
| No subroutines.
|
| No comments.
|
| Three-letter variable names.
|
| LOTS of GOTOs.
|
| VT-100 300-Baud terminals.
|
| Inspired me to never do that to anyone else[0].
|
| [0] https://littlegreenviper.com/leaving-a-legacy/
| Quekid5 wrote:
| > 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.
|
| Yeah, that's it, isn't it? I could probably make a career off
| of tiny incremental improvements to some terrible business
| app... or I could ... care. (I do realize the drip of sarcasm
| in your post, don't worry)
|
| Anyway, hail Mammon, I suppose, innit? Unless...
| cogman10 wrote:
| A nice aspect of big balls of mud is you can plow over small
| sections to make gardens. Once you accept that completely
| dumping the ball of mud is impossible, you can just "do a good
| turn daily". Clean up a little code here, there, everywhere.
| Most people working on balls of mud don't care that you do this
| (provided you aren't completely rewriting 90% of the system).
|
| You'll still have to regularly get dirty, but the petunias you
| grew over the years form nice memories.
| mbostleman wrote:
| The Boy Scout rule.
| mvdtnz wrote:
| The problem is that all of this time "plowing fields" and
| "doing a good turn daily" could have been avoided, and when a
| big ball of mud gets really hairy this can easily turn into
| the bulk of your work day and dominate projects. It can cause
| a company to deliver slowly and miss opportunities.
| cogman10 wrote:
| > could have been avoided
|
| Hard to know if that's true or not. Some code goes on for
| literally decades before being touched by another person.
| Often times, the parts of the code that are high touch end
| up justifying more gardening to make future touches less
| painful/faster.
|
| Knowing when code will be cumbersome is really difficult
| when writing fresh.
| mvdtnz wrote:
| Games are a different story, especially single player games
| without a live service component. Most of us write software
| that needs to be maintained and iterated on. It has nothing to
| do with "finding meaning" in work and everything to do with
| delivering to a reasonable standard in a reasonable time in a
| sustainable way.
| gorgoiler wrote:
| I have found that implementing a regression test suite for such
| systems is a really good way of holding a mirror up to the mud
| ball and showing it what it could look like if it smartened
| itself up a bit. If it's too much to apply some discernment and
| modularity to the underlying codebase then you can instead do
| this with the test suite and reflect those discoveries back
| into the codebase with the benefit that you can now prove your
| changes don't break the documented, expected behaviour.
|
| It's like rewriting the code but by passing the ball from
| production code to test code and back to figure out who the
| individual players are.
| free_bip wrote:
| 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.
| bazoom42 wrote:
| How did you measure the 3x factor?
| free_bip wrote:
| Mostly 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.
| jmull wrote:
| Hmmm... 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.
| mvdtnz wrote:
| There's no reason to believe that people, teams and
| organisations can't learn lessons. This is why we foster a
| growth mindset. It takes effort and discipline but it can be
| done.
| pylua wrote:
| I feel like this is typically not the right choice.
| klyrs wrote:
| > ....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.
|
| What fraction of developers is on Team Rewrite?
| speed_spread wrote:
| Have you considered the possibility that 3x as many programmers
| were always dedicated to the project made it grow into the big
| ball of mud that it is?
|
| Team size correlates with system complexity regardless of the
| problem domain.
| 1penny42cents wrote:
| What's the correlation between code quality and business success?
| Jtsummers wrote:
| Depends 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 wrote:
| Nobody knows, since there is no agreed-upon way to measure code
| quality.
| Ma8ee wrote:
| I'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?
| hitchstory wrote:
| 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.
| gedy wrote:
| The article calls these folks "swamp guides"
| worstspotgain wrote:
| > a mixture between a crossword puzzle and archaeology
|
| Cue cave escape scene chased by huge rolling boulder.
| antimora wrote:
| 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.
| jallmann wrote:
| Feels 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 wrote:
| 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.
| AnimalMuppet wrote:
| 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!
| aidenn0 wrote:
| 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_
| rurban wrote:
| I can also recommend the whole book "AntiPatterns", with many
| more such Anti-patterns. http://antipatterns.com/thebook.htm
| delichon wrote:
| 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.
| bozhark wrote:
| Who links images you have to login to view?
| trhway wrote:
| 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.
___________________________________________________________________
(page generated 2024-07-10 23:00 UTC)