My experience is that amount of refactoring is inversely proportional to the amount of people working on the code base and directly proportional to the freshness of the code.
In other words, I refactor so much more the fresh code to make it as good as I can, as I know for sure that other devs wouldn't be resolving conflicts as a result of my refactoring. On the other hand, the more people are working on the shared code, more "differently" old branches the code base has, the more chances that even the smallest refactoring could lead to other developer's pain, or maintenance pain, or production pain. I tend not to refactor as much in that case, or rather prefer the approach of write new and replace, as bigger chunks are easier to resolve than a conflict spaghetti.
To me the refactoring is a delicate balance between empathy to other developers, freshness of the code and the size of the team.
With large teams it is better not to refactor much if you want to keep delivering usable software, hence over time the codebase begins to smell like a pile of turd.
I work in many projects, some small, some big and some personal. And yeah, it's a lot easier when you're alone or in rather small and new projects. But I think it's important to do it in such projects, as to make them be in the best shape possible before it becomes a big project or many people start working on it. As later on it's harder to do as you mentioned.
hence over time the codebase begins to smell like a pile of turd
I have a couple of those at our company, they smell from 5 miles away lol
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
My experience is that amount of refactoring is inversely proportional to the amount of people working on the code base and directly proportional to the freshness of the code.
In other words, I refactor so much more the fresh code to make it as good as I can, as I know for sure that other devs wouldn't be resolving conflicts as a result of my refactoring. On the other hand, the more people are working on the shared code, more "differently" old branches the code base has, the more chances that even the smallest refactoring could lead to other developer's pain, or maintenance pain, or production pain. I tend not to refactor as much in that case, or rather prefer the approach of write new and replace, as bigger chunks are easier to resolve than a conflict spaghetti.
To me the refactoring is a delicate balance between empathy to other developers, freshness of the code and the size of the team.
With large teams it is better not to refactor much if you want to keep delivering usable software, hence over time the codebase begins to smell like a pile of turd.
I like this one, and can relate.
I work in many projects, some small, some big and some personal. And yeah, it's a lot easier when you're alone or in rather small and new projects. But I think it's important to do it in such projects, as to make them be in the best shape possible before it becomes a big project or many people start working on it. As later on it's harder to do as you mentioned.
I have a couple of those at our company, they smell from 5 miles away lol