4 ms·

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

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

geekone 2y ago
Yeah 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 ago
At 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.
- lanstin 2y ago
  Someone once had me code review a 2500 line bash script, written like a Cobol program, but with no error checking of anything. I'm not sure what my point is, but sometimes I am surprised civilization still works as well as it does.
- alexpotato 2y ago
  >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. I've seen this SO MANY times too. Nothing like having 8 files open to debug what turns out to be a one line change due to all of the object inheritance.

geekone 2y ago

Yeah 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 ago

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

lanstin 2y ago
Someone once had me code review a 2500 line bash script, written like a Cobol program, but with no error checking of anything. I'm not sure what my point is, but sometimes I am surprised civilization still works as well as it does.
alexpotato 2y ago
>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. I've seen this SO MANY times too. Nothing like having 8 files open to debug what turns out to be a one line change due to all of the object inheritance.