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.

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.