7 ms·

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 gam

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 2y ago
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 2y ago
  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 2y ago
    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 2y ago
      Why would such a system assure someone that it worked? Conversely, why would only the succinct version lend itself to a subtle bug?
      - codetrotter 2y ago
        Mine is as succinct as they come, but a little bit buggy int is_leap_year(int year) { return 0; }
        wewtyflakes 2y ago
        I don't think that qualifies as a "subtle" bug. :)
      - throwway120385 2y ago
        Suppose that someone tried to naively derive the leap year by dividing the current year by 4. There are some years that are divisible by 4 but that are nonetheless not leap years. If you fail to account for this in your succinct implementation then you might introduce a leap day that doesn't exist at some point. I know the table implementation seems really dumb, and it's not that hard to look up a correct algorithm for this, but it's a good example. If you build a table from some correct source then you can simply use that table instead of running a calculation. There are fewer than 30 leap years in the next 100 years, by which time something cataclysmic will happen that will completely erase the need for your code anyway. At least, you will be dead before you need to revise the code again. So it's reasonable to build a function with a table given the time-limited nature of the code and the desire to be visibly and explicitly correct. Sure you could add a unit test with the table and test the calculation, but that actually adds more code to maintain than just jamming the table directly into the function.
- pixl97 2y ago
  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 2y ago
    >> "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 2y ago
      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.
  - daemin 2y ago
    The part with having multiple libraries that do the same thing is always an interesting engineering case. Usually it's the case that different libraries support different features, so trying to settle on only one library is folly. Same thing when converting all of the existing zip code to handle a new library, who knows what will break, and even though it may be required production/management rarely want to take the time to make the switch. Case in point I've been at multiple places that have had multiple JSON and XML libraries in the same product at the same time.
- Quekid5 2y ago
  Turing Machines have that property. There the Tarpit lies.
ChrisMarshallNY 2y ago
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/ https://littlegreenviper.com/leaving-a-legacy/
- vharuck 2y ago
  >Three-letter variable names. You're giving me flashbacks to all the SAS code I inherited. The tables had three-letter names like "AAA" and "BBB", and all the columns had single-letter names. Wasn't long before I completely rewrote the entire thing (a couple times, because I wrote junk, too).
  - jprete 2y ago
    When I hear stories of programmers who put a moat around their jobs with incomprehensible code, I usually assume it's exaggerated, but in your case I wonder if that's exactly what happened.
Quekid5 2y ago
> 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...
- forgetfreeman 2y ago
  Care about what though? Given how frequently paradigms shift in the meta of software development investing in this space on an emotional level plants you (and your project) squarely on a treadmill. If it meets spec and the bugs are mostly corralled what else is there really?
cogman10 2y ago
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 2y ago
  The Boy Scout rule.
- mvdtnz 2y ago
  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.
  - DowagerDave 2y ago
    for every big ball of mud there's 10 premature optimizations
  - cogman10 2y ago
    > 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.
    - throwaway2037 2y ago
      > could have been avoided I complete agree with your sentiment. Too many of these commenters are unrealistic: In most cases you cannot avoid the BBoM. Usually, it is written by someone before you... or above you... so you have little power to change it, but you can make meaningful changes step by step.
deleted 2y ago
[deleted]
mvdtnz 2y ago
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 2y ago
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.
KronisLV 2y ago
> Believe it or not, being hired to work on a big ball of mud can be pretty chill. Probably depends on how big the ball is and how messy the mud. If you’re not careful, you might find yourself drowning in a whole swamp instead: https://news.ycombinator.com/item?id=18442941 https://news.ycombinator.com/item?id=18442941 Once you have to dig through dozens of files full of hacks and bad abstractions just to make basic changes and even then the insufficient test suite prevents you from being confident in any positive outcome (the example above at least had good tests, often you don’t even get that much), maybe things aren’t going great. That said, you can definitely write good monoliths and even codebases with technical debt can be pleasant, as long as things are kept as simple as possible.
MathMonkeyMan 2y ago
A big ball of mud is never what's needed. It's just what happens when too many people have cared too little for too long. I suspect that the perspective of "It sucks but it works for us; I'm not idealistic anymore" is really a rationalization of despair, but that's just me.
- forgetfreeman 2y ago
  I couldn't disagree more. Given time and budget constraints and the tendency for code/services/entire business models to deprecate in less than a decade heavy architecture should be the last thing that anyone reaches for and only after a need has been comprehensively proven for it. Over the decades I've lost count of how many project budgets have been blown to hell by well-intentioned, well-educated, experienced, and competent developers attempting to apply whatever architectural best practices du jour (the churn in this space is telling). End of the day it's still just code. There will still be bugs and it'll still be a pain in someone's ass to deal with. KISS uber alles.
  - PaulStatezny 2y ago
    Sounds like you're saying either: 1. Engineers don't care about the health of the codebase and it becomes/stays a ball of mud, OR... 2. They do care, and end up refactoring/rewriting it in a way that just creates even MORE complexity. But I think this is a false dichotomy. It just happens to be very difficult, and as much of an art as a science to keep huge codebases moving in the right direction. I haven't worked at Google, but from what I've heard they have huge codebases, but they're not typically falling apart at the seams.
    - forgetfreeman 2y ago
      1. I reject the notion that a ball of mud signifies lack of care. Nobody gets up in the morning planning on shooting themselves in the foot daily for the next N years and culturally devs aren't great about embracing the healthy benefits of pragmatism. With few exceptions architectural best practices are either largely esthetic or born from the particular constraints of specific tech stack and then leak due to concerted evangelical efforts by individuals polishing their street cred and organizations eager to bolster their in-house devs with unwitting volunteers (see also the near complete capture of open source by industry). 2. They absolutely care, but possibly about the wrong things, and this happens so often it's a cliche. Remember when a big chunk of the industry woke up one moring and decided RDBMs just had to be bullshit because my god look how old they are and collectively dove themselves, their projects, and their organizations off the cliff that was shoehorning mapreduce into a project NOT owned by Google? Speaking of Google, I feel like there are few things less relevant to the industry writ large than whatever they happen to be up to at any given moment. From tech stack to hiring practices their needs are so totally orthogonal to what any other org requires they honestly may as well be operating in another dimension. Chasing after Google is like running around with a fork in your hand in search of a wall outlet. Anyway, to finish up my thoughts on architecture as a concept, yeah having some structure to a codebase is something of a no-brainer, but dogma is as dogma does. There are very few unimpeachable capital T truths come from the software architecture intelligentsia. We could talk at some length about the decades of churn in this space as roughly every 5 years another crop of grad students gets unleashed into the industry dead-ass certain that they have found The Way.
resonious 2y ago
I honestly don't get why things like giant switch statements are even considered bad or smelly. You have to put the dialog somewhere. What's the material difference between putting it in a switch statement vs separate functions vs named text files? The dialog isn't going away. You still have tons of dialog. Even for regular code organization. 100 small functions is ok but 100 switch cases is bad? It's the same amount of code, and switch cases aren't that "hard to read".
- YurgenJurgensen 2y ago
  100 small functions that only get called in one place is also bad. It implies that most of them are slight permutations of each other and can be cut with the right parameterisaton. Unless your logic genuinely has 100 qualitatively unique special cases, and in that case, you’re probably screwed, as there are no elegant solutions.
- yyhhsj0521 2y ago
  For one, changing a typo shouldn't require any code to be recompiled.
  - daemin 2y ago
    Having all the dialog logic in a single switch statement doesn't mean that all the text is right in there. It can still be referring to IDs which are then looked up in a table for the right translation.
    - YurgenJurgensen 2y ago
      That would still be a step above the Undertale case, where the dialog was in the code. The big problem there is that your localisers now need your source code and (potentially expensive commercial) build system to test that their script doesn’t break anything. Or you end up in an expensive back-and-forth with a contractor compiling it for them. Just taking localisation strings out of the switch statement doesn’t fully fix this. You can swap out individual lines, but characters are still bound to say the same number of lines in the same order in every language, with player choice happening at the same point. This may work for simple conversations, but it will result in clunky localisations when languages differ in verbosity or sentence structure.
lordnacho 2y ago
Yeah this is right. It's like being a software oncologist. Often there's nothing to do. The patient is somewhat ok, and intervening would mean risking death due to the tumour being near some critical blood vessel. At most you have some routine maintenance to do on a daily basis. Cut some things here and there, reroute a few small things, tell the patient they need this or that medicine. You might even find it interesting to learn how the body of code works, the journal of previous surgeons, the little nooks and crannies where interesting decisions are made. But you are never asked to rebuild the entire body.
eweise 2y ago
"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." Big balls of mud at banks, are a liability these days. They are under increased competition from fintechs that are have better codebases and processes, and can add features much more quickly.
- PaulStatezny 2y ago
  Came here to express the same sentiment. > Sometimes a big ball of mud is exactly what’s needed...Banks are another example...It’s soul crushing...which is partly why I left. Not a very convincing argument. ;-)
antfarm 2y ago
> Sometimes a big ball of mud is exactly what’s needed. And if you wait a little while, what you need is new developers.
harrison_clarke 2y ago
big ball of mud is a great pattern for games (non live-service ones, at least) once you ship, you don't really need to maintain it the same way as other software. tech debt is free money if you ship before having to pay it back and players often like complexity and interaction between systems, so there's less benefit to isolating them in code
- YurgenJurgensen 2y ago
  Looking at some high-profile games that never shipped, that’s a very risky gamble if you don’t know when the bailiff will come to collect.
deleted 2y ago
[deleted]

nyrikki 2y ago

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 2y ago
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 2y ago
  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 2y ago
    Why would such a system assure someone that it worked? Conversely, why would only the succinct version lend itself to a subtle bug?
    - codetrotter 2y ago
      Mine is as succinct as they come, but a little bit buggy int is_leap_year(int year) { return 0; }
      - wewtyflakes 2y ago
        I don't think that qualifies as a "subtle" bug. :)
    - throwway120385 2y ago
      Suppose that someone tried to naively derive the leap year by dividing the current year by 4. There are some years that are divisible by 4 but that are nonetheless not leap years. If you fail to account for this in your succinct implementation then you might introduce a leap day that doesn't exist at some point. I know the table implementation seems really dumb, and it's not that hard to look up a correct algorithm for this, but it's a good example. If you build a table from some correct source then you can simply use that table instead of running a calculation. There are fewer than 30 leap years in the next 100 years, by which time something cataclysmic will happen that will completely erase the need for your code anyway. At least, you will be dead before you need to revise the code again. So it's reasonable to build a function with a table given the time-limited nature of the code and the desire to be visibly and explicitly correct. Sure you could add a unit test with the table and test the calculation, but that actually adds more code to maintain than just jamming the table directly into the function.
pixl97 2y ago
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 2y ago
  >> "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 2y ago
    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.
- daemin 2y ago
  The part with having multiple libraries that do the same thing is always an interesting engineering case. Usually it's the case that different libraries support different features, so trying to settle on only one library is folly. Same thing when converting all of the existing zip code to handle a new library, who knows what will break, and even though it may be required production/management rarely want to take the time to make the switch. Case in point I've been at multiple places that have had multiple JSON and XML libraries in the same product at the same time.
Quekid5 2y ago
Turing Machines have that property. There the Tarpit lies.

ChrisMarshallNY 2y ago

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/ https://littlegreenviper.com/leaving-a-legacy/

vharuck 2y ago
>Three-letter variable names. You're giving me flashbacks to all the SAS code I inherited. The tables had three-letter names like "AAA" and "BBB", and all the columns had single-letter names. Wasn't long before I completely rewrote the entire thing (a couple times, because I wrote junk, too).
- jprete 2y ago
  When I hear stories of programmers who put a moat around their jobs with incomprehensible code, I usually assume it's exaggerated, but in your case I wonder if that's exactly what happened.

Quekid5 2y ago

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

forgetfreeman 2y ago
Care about what though? Given how frequently paradigms shift in the meta of software development investing in this space on an emotional level plants you (and your project) squarely on a treadmill. If it meets spec and the bugs are mostly corralled what else is there really?

cogman10 2y ago

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 2y ago
The Boy Scout rule.
mvdtnz 2y ago
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.
- DowagerDave 2y ago
  for every big ball of mud there's 10 premature optimizations
- cogman10 2y ago
  > 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.
  - throwaway2037 2y ago
    > could have been avoided I complete agree with your sentiment. Too many of these commenters are unrealistic: In most cases you cannot avoid the BBoM. Usually, it is written by someone before you... or above you... so you have little power to change it, but you can make meaningful changes step by step.

deleted 2y ago

[deleted]

mvdtnz 2y ago

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 2y ago

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.

KronisLV 2y ago

> Believe it or not, being hired to work on a big ball of mud can be pretty chill. Probably depends on how big the ball is and how messy the mud. If you’re not careful, you might find yourself drowning in a whole swamp instead: https://news.ycombinator.com/item?id=18442941 https://news.ycombinator.com/item?id=18442941 Once you have to dig through dozens of files full of hacks and bad abstractions just to make basic changes and even then the insufficient test suite prevents you from being confident in any positive outcome (the example above at least had good tests, often you don’t even get that much), maybe things aren’t going great. That said, you can definitely write good monoliths and even codebases with technical debt can be pleasant, as long as things are kept as simple as possible.

MathMonkeyMan 2y ago

A big ball of mud is never what's needed. It's just what happens when too many people have cared too little for too long. I suspect that the perspective of "It sucks but it works for us; I'm not idealistic anymore" is really a rationalization of despair, but that's just me.

forgetfreeman 2y ago
I couldn't disagree more. Given time and budget constraints and the tendency for code/services/entire business models to deprecate in less than a decade heavy architecture should be the last thing that anyone reaches for and only after a need has been comprehensively proven for it. Over the decades I've lost count of how many project budgets have been blown to hell by well-intentioned, well-educated, experienced, and competent developers attempting to apply whatever architectural best practices du jour (the churn in this space is telling). End of the day it's still just code. There will still be bugs and it'll still be a pain in someone's ass to deal with. KISS uber alles.
- PaulStatezny 2y ago
  Sounds like you're saying either: 1. Engineers don't care about the health of the codebase and it becomes/stays a ball of mud, OR... 2. They do care, and end up refactoring/rewriting it in a way that just creates even MORE complexity. But I think this is a false dichotomy. It just happens to be very difficult, and as much of an art as a science to keep huge codebases moving in the right direction. I haven't worked at Google, but from what I've heard they have huge codebases, but they're not typically falling apart at the seams.
  - forgetfreeman 2y ago
    1. I reject the notion that a ball of mud signifies lack of care. Nobody gets up in the morning planning on shooting themselves in the foot daily for the next N years and culturally devs aren't great about embracing the healthy benefits of pragmatism. With few exceptions architectural best practices are either largely esthetic or born from the particular constraints of specific tech stack and then leak due to concerted evangelical efforts by individuals polishing their street cred and organizations eager to bolster their in-house devs with unwitting volunteers (see also the near complete capture of open source by industry). 2. They absolutely care, but possibly about the wrong things, and this happens so often it's a cliche. Remember when a big chunk of the industry woke up one moring and decided RDBMs just had to be bullshit because my god look how old they are and collectively dove themselves, their projects, and their organizations off the cliff that was shoehorning mapreduce into a project NOT owned by Google? Speaking of Google, I feel like there are few things less relevant to the industry writ large than whatever they happen to be up to at any given moment. From tech stack to hiring practices their needs are so totally orthogonal to what any other org requires they honestly may as well be operating in another dimension. Chasing after Google is like running around with a fork in your hand in search of a wall outlet. Anyway, to finish up my thoughts on architecture as a concept, yeah having some structure to a codebase is something of a no-brainer, but dogma is as dogma does. There are very few unimpeachable capital T truths come from the software architecture intelligentsia. We could talk at some length about the decades of churn in this space as roughly every 5 years another crop of grad students gets unleashed into the industry dead-ass certain that they have found The Way.

resonious 2y ago

I honestly don't get why things like giant switch statements are even considered bad or smelly. You have to put the dialog somewhere. What's the material difference between putting it in a switch statement vs separate functions vs named text files? The dialog isn't going away. You still have tons of dialog. Even for regular code organization. 100 small functions is ok but 100 switch cases is bad? It's the same amount of code, and switch cases aren't that "hard to read".

YurgenJurgensen 2y ago
100 small functions that only get called in one place is also bad. It implies that most of them are slight permutations of each other and can be cut with the right parameterisaton. Unless your logic genuinely has 100 qualitatively unique special cases, and in that case, you’re probably screwed, as there are no elegant solutions.
yyhhsj0521 2y ago
For one, changing a typo shouldn't require any code to be recompiled.
- daemin 2y ago
  Having all the dialog logic in a single switch statement doesn't mean that all the text is right in there. It can still be referring to IDs which are then looked up in a table for the right translation.
  - YurgenJurgensen 2y ago
    That would still be a step above the Undertale case, where the dialog was in the code. The big problem there is that your localisers now need your source code and (potentially expensive commercial) build system to test that their script doesn’t break anything. Or you end up in an expensive back-and-forth with a contractor compiling it for them. Just taking localisation strings out of the switch statement doesn’t fully fix this. You can swap out individual lines, but characters are still bound to say the same number of lines in the same order in every language, with player choice happening at the same point. This may work for simple conversations, but it will result in clunky localisations when languages differ in verbosity or sentence structure.

lordnacho 2y ago

Yeah this is right. It's like being a software oncologist. Often there's nothing to do. The patient is somewhat ok, and intervening would mean risking death due to the tumour being near some critical blood vessel. At most you have some routine maintenance to do on a daily basis. Cut some things here and there, reroute a few small things, tell the patient they need this or that medicine. You might even find it interesting to learn how the body of code works, the journal of previous surgeons, the little nooks and crannies where interesting decisions are made. But you are never asked to rebuild the entire body.

eweise 2y ago

"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." Big balls of mud at banks, are a liability these days. They are under increased competition from fintechs that are have better codebases and processes, and can add features much more quickly.

PaulStatezny 2y ago
Came here to express the same sentiment. > Sometimes a big ball of mud is exactly what’s needed...Banks are another example...It’s soul crushing...which is partly why I left. Not a very convincing argument. ;-)

antfarm 2y ago

> Sometimes a big ball of mud is exactly what’s needed. And if you wait a little while, what you need is new developers.

harrison_clarke 2y ago

big ball of mud is a great pattern for games (non live-service ones, at least) once you ship, you don't really need to maintain it the same way as other software. tech debt is free money if you ship before having to pay it back and players often like complexity and interaction between systems, so there's less benefit to isolating them in code

YurgenJurgensen 2y ago
Looking at some high-profile games that never shipped, that’s a very risky gamble if you don’t know when the bailiff will come to collect.

deleted 2y ago

[deleted]