> "Working Effectively with Legacy Code" defines legacy code as code without tests thus hard to change it easily or with confidence.
This is not a universally accepted definition. I've owned plenty of services with 95%+ unit test coverage, massive integ test suites, and synthetic canary tests that ran every minute that I would consider legacy. Plenty of AI slop today gets barfed out with 100% test coverage, but much of it is legacy from day 1.
I aggree thre are many defs. I only used that ex as it's easy to use and understand.
What would you consider legacy? (not trynna fight, just wondering what you consider as one)
Workloads that either are superseded or there is a desire to supersede them. It's not just old deprecated stuff, but also stuff that people want to deprecate.
An example could be old API endpoints only hit by old versions of a mobile app where users may be slow to update. Or a case where only newer clients/instances support modern features and old ones are stuck on a frozen featureset until they cutover.
But active services with no immediately existant alternative may also be legacy. If your auth is behind a disappointing managed service like AWS Cognito, you may consider your entire auth stack legacy while the replacement is still looming in the roadmap down the line. Maybe you can't justify funding to work on a transition just yet, but you already would avoid building on top of the existing tech stack.