From working with an old PHP codebase, I'd like to offer: "Design for deletion."

This has important differences from "design for modularity" or "design for future change" or "design so someone can swap it out", because those phrases tend to make developers go off and engineer extra stuff, under the assumption that their current paradigm for how the software operates is going to continue to be accurate even if their implementation someday needs replacing.

... But what happens when it's not just "this code sucks", but also "we shouldn't even have any code that's doing this task"?