this is a good post, but there's missing context about the kinds of situations where this approach can work, and what distinguishes them from situations where this kind of incremental long-term refactor approach is unlikely to be feasible.
contexts that could make this approach more feasible:
- it's technically feasible to incrementally transition from the current state to the target state. there's a variety of safe stopping points where the system can be in a weird hybrid partially-refactored state, and continue to function, pass QA and ship.
- the changes that need to be made in order to transition from current state to target state are internal to a single component owned by one team, and don't require changes to any external APIs / interfaces, or large-scale coordinated migration activities by internal/external consumers or dependencies or users
contexts that could make this approach more feasible:
- it's technically feasible to incrementally transition from the current state to the target state. there's a variety of safe stopping points where the system can be in a weird hybrid partially-refactored state, and continue to function, pass QA and ship.
- the changes that need to be made in order to transition from current state to target state are internal to a single component owned by one team, and don't require changes to any external APIs / interfaces, or large-scale coordinated migration activities by internal/external consumers or dependencies or users