Skip to content

Ask HN: What's the hardest part of maintaining a legacy codebase?

3 pointsrafaepta5 comments
On HN

Comments

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.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.