Ask HN: What's the hardest part of maintaining a legacy codebase?
Hands down, the urge of product to assume that codebase is stable and as nimble as a greenfield project, and so any feature can be build with minimal “we just need to make a small change in feature X to do Y”, while never allowing for resources to allow the legacy codebase to keep pace with new features.
The tiniest feature becomes a chess game with unpredictable interactions, not enough tests, etc.
I feel like this applies to all code bases not just legacy ones!
It's setting developers up to default-fail and making them accountable if they do, and the crazy thing is companies insist on this when a solid test suite and occasional cleanup drastically reduces the possibility of failing... setting developers up to default-win.
Legacy expectations and requirements. It's not uncommon to see that there is a better way to do something, but be unable to do it because the customer assumes and/or expects the current way of doing things. They might even be on board with the new way, but trying to include that in any sort of project budget is a non- starter.
Can't transfer your skills to the shiny new thing.
fighting the urge to rewrite everything and propagating the legacy code cycle.