Earlier quoted context omitted.
As someone who's spent 12 years working on legacy codebases, I strongly disagree with this. Iterative work in a large legacy codebase is how you end up making your large legacy codebase larger and even less understood. Your planning should "wade into the code" from the start. I have always gotten better results by charting out flow diagrams and whiteboarding process changes than just "diving in and changing stuff". F…
> I have always gotten better results by charting out flow diagrams and whiteboarding process changes than just "diving in and changing stuff". In terms of a broad population, I am not sure there is a meaningful difference, though. You can iterate on your ideas on the whiteboard or you can iterate on your ideas in code, but the intent is the same. Either way you are going to throw it all away once you have settled on…
Ultimately what matters is the final changeset. How you get there doesn't really matter.