4 ms·

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, y

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.
    - wesselbindt 2y ago
      In all fairness, they didn't say "could've been avoided by you specifically" rather "could have been avoided". And this I'm inclined to agree with
      - watwut 2y ago
        One issue is that the hardest to maintain code I have seen was written by well meaning people who have really put themselves into it. They just made a wrong decision somewhere, because they were not gods.
  - lll-o-lll 2y ago
    > Knowing when code will be cumbersome is really difficult when writing fresh. I think a large part of what goes wrong is that code starts out too simple. When you look back at the history of the code, the original check-ins almost always look good. Good, but very “direct”. Here was the problem, and here we have solved it as bluntly as possible. As the changes come, they often break concepts that were introduced in those first few check-ins. It’s understandable, the person coming after is just trying to add “that one thing” with as small a change as possible. These accumulate, and soon any semblance of a logical “model” has been lost. A bit of “build an example for others to follow” at the beginning, might have saved things down the track. However, do too much “over-engineering”, and no one is checking in your code, and you might be wasting tons of effort. Hence, experience is required to know the basic pitfalls that develop, and where you need to put in the extra for that initial check-in. Many code-bases, of course, are started by people without that experience, and balls of mud inevitably develop. You can refactor them! It’s carve out chunks, partition them off, keep the two in parallel until the new is as stable as the old. Banks have actually done this; not all of them. The reality is that if you don’t, new features simply cost too much to be worth developing. You can eventually be completely paralysed by technical debt.
kreyenborgi 2y ago
I had this field of mudballs where I kept getting bug reports related to this particularly muddy ball, and I kept slapping on more mud (always in a rush) and it never quite fixed it. Eventually I had read that code so much I almost knew it by heart, I had spent so much time there. And one night the new design appeared in my head. I suspected it would take only a few hours to implement. And, sure enough, five days and a few evenings later I had turned it into a beautiful garden. It passed all tests, it hummed like a well-oiled bee, it was awesome to behold. And then, because it generated no bug reports, I never looked at it again; and I spent the rest of my days there slapping dirt and water on the other mudballs.
- DowagerDave 2y ago
  that's an awesome analogy, built very similarly to the system it describes :)
pphysch 2y ago
> Clean up a little code here, there, everywhere. What does "clean up" mean? If you mean run a safe code formatter on some 20 year old PHP code that was written in vi, sure. But if you mean refactor, this sounds rather idealistic. IMO, you are already outside of BBOM territory if your BBOM comes with a robust development environment where you can safely implement such changes without breaking prod in some insane and unforeseeable way.

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.
  - wesselbindt 2y ago
    In all fairness, they didn't say "could've been avoided by you specifically" rather "could have been avoided". And this I'm inclined to agree with
    - watwut 2y ago
      One issue is that the hardest to maintain code I have seen was written by well meaning people who have really put themselves into it. They just made a wrong decision somewhere, because they were not gods.
- lll-o-lll 2y ago
  > Knowing when code will be cumbersome is really difficult when writing fresh. I think a large part of what goes wrong is that code starts out too simple. When you look back at the history of the code, the original check-ins almost always look good. Good, but very “direct”. Here was the problem, and here we have solved it as bluntly as possible. As the changes come, they often break concepts that were introduced in those first few check-ins. It’s understandable, the person coming after is just trying to add “that one thing” with as small a change as possible. These accumulate, and soon any semblance of a logical “model” has been lost. A bit of “build an example for others to follow” at the beginning, might have saved things down the track. However, do too much “over-engineering”, and no one is checking in your code, and you might be wasting tons of effort. Hence, experience is required to know the basic pitfalls that develop, and where you need to put in the extra for that initial check-in. Many code-bases, of course, are started by people without that experience, and balls of mud inevitably develop. You can refactor them! It’s carve out chunks, partition them off, keep the two in parallel until the new is as stable as the old. Banks have actually done this; not all of them. The reality is that if you don’t, new features simply cost too much to be worth developing. You can eventually be completely paralysed by technical debt.

kreyenborgi 2y ago

I had this field of mudballs where I kept getting bug reports related to this particularly muddy ball, and I kept slapping on more mud (always in a rush) and it never quite fixed it. Eventually I had read that code so much I almost knew it by heart, I had spent so much time there. And one night the new design appeared in my head. I suspected it would take only a few hours to implement. And, sure enough, five days and a few evenings later I had turned it into a beautiful garden. It passed all tests, it hummed like a well-oiled bee, it was awesome to behold. And then, because it generated no bug reports, I never looked at it again; and I spent the rest of my days there slapping dirt and water on the other mudballs.

DowagerDave 2y ago
that's an awesome analogy, built very similarly to the system it describes :)

pphysch 2y ago

> Clean up a little code here, there, everywhere. What does "clean up" mean? If you mean run a safe code formatter on some 20 year old PHP code that was written in vi, sure. But if you mean refactor, this sounds rather idealistic. IMO, you are already outside of BBOM territory if your BBOM comes with a robust development environment where you can safely implement such changes without breaking prod in some insane and unforeseeable way.