Ever faced a codebase that had it’s last commit some years ago?
Either you have a bug to fix or a new feature that was asked implement, you will open up that text-editor/IDE and face off with old code. Right off the bat, it looks pretty “wrong”, even if you yourself wrote it. The only exceptional pieces of “old code” are parts you never have to open, because 1) they’re working exactly the way people need it to work and 2) users don’t ask for anything more than that.
People write code without a clear glimpse of the future. Some people do try their best to future-proof certain parts of the code, but it’s still written with uncertainty.
A few years pass and new things need to happen. Developers roll up their sleeves and see new opportunities of abstraction, new processes to pull out and modularize.
The thing is, those who work on top of the old code have the advantage of looking backwards, they can write the “thing” that can solve what really needs solving. That’s why no matter how pretty some patches of code presently look, they will almost always look crude in the future.
No matter how bad it looks, nobody can really blame previous developers; unless they didn’t have a firm grasp of the framework the software was built upon in the first place, but that’s a totally different story.
Besides, in the near future, even our “shiny new code” will suffer the same fate.