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"?
Thanks. When it comes to "easily refactor" I think there's a distinction to be drawn between "hard but understandable and verifiable" versus "maybe-easy but with unknown surprises."
The difficulty of replacing or refactoring code should come from the "inherent complexity" of creating its replacement, not from the "incidental complexity" of discovering its boundaries and influence.
Comments
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"?
I love this idea. If you can easily delete the code, you can easily refactor!
Thanks. When it comes to "easily refactor" I think there's a distinction to be drawn between "hard but understandable and verifiable" versus "maybe-easy but with unknown surprises."
The difficulty of replacing or refactoring code should come from the "inherent complexity" of creating its replacement, not from the "incidental complexity" of discovering its boundaries and influence.