Aye, I agree completely. When approaching a given rewrite, I'm very hesitant to go through with it unless I have a strong understanding of all the files I'm about to have to touch to fix the resulting compiler errors. Ideally this should be straightforward, but the tight coupling often observed in poorly maintained codebases can cause the most innocent of small changes to spiral out into the template metaprogramming circle of death.
Even then though, all is not lost! When faced with an architecture change that really should be made, but is too large to make right now, I make a note of it on a project board somewhere and now I have a new sub-task. Any time I touch code elsewhere, I work to reduce coupling and correct dependency issues, so that the original change is easier to make. By slowly cleaning up small parts of the code, I open the door to making the larger rewrite not quite so large when I get around to it, and hopefully improve the project's overall quality in the process. In this way, I create forward progress towards the end goal without needing to commit to all of it at once.
Even then though, all is not lost! When faced with an architecture change that really should be made, but is too large to make right now, I make a note of it on a project board somewhere and now I have a new sub-task. Any time I touch code elsewhere, I work to reduce coupling and correct dependency issues, so that the original change is easier to make. By slowly cleaning up small parts of the code, I open the door to making the larger rewrite not quite so large when I get around to it, and hopefully improve the project's overall quality in the process. In this way, I create forward progress towards the end goal without needing to commit to all of it at once.