4 ms·
I was thinking of making a comment here, describing this as precisely my experience. I work on an old legacy system. I have done so for some time, from junior t
by squiggleblaz 9y ago
I was thinking of making a comment here, describing this as precisely my experience. I work on an old legacy system. I have done so for some time, from junior to lead. [Edit: wait, I meant to say "i have discovered this same principle but you expressed it better than me". instead, i just described my experience.]
And I can see from experience that every refactor we did that was "this is the latest and greatest and we'll write the new feature like this and we'll just start migrating everything over to this eventually" has been an utter failure.
But the changes that were by their nature spread throughout the system automatically have been so much easier to work with. You don't even notice them. (Which makes it harder to get credit for it. If I have to train a new dev up today, I can say "the system is a little crappy, but we're trying to make it better". But they'll never see that we've made huge progress. But they will see the four different database abstractions we've got going on and they'll curse me, because this is where you see some work.
It is better to have a crappy core that you gradually fix, then do have a crappy core that remains there and five crappy other cores from each different dev. And whatever problems are caused by the shitty database abstraction some idiot dev created are always going to be there, so you might as well just live in that world.
- jknoepfler 9y agoi really appreciate your taking the time to write up your experiences in response, thank you. I think it's really important to continually articulate hard, possibly unpopular truths learned through experience. Otherwise how will our children's children have anywhere to look for guidance (lol... but seriously)