[jrochkind1]

Ideally you need something in the middle of "Rewrite this whole damn thing from scratch" and "don't touch a thing more than you need to, never change any architecture, just make it work and the tests pass."

You need to understand the existing architecture and idioms and traits. And you need to understand the business domain. Then you need to decide when it makes sense to refactor a sub-system first to make the change easier (and support future such changes, which requires you to make a _guess_ as to how likely future such changes are), or to resolve existing lingering problems while making your change easier. And when it doesn't. And you hardly ever, ever, need to rewrite the whole thing (but not never, just hardly ever).

Personally, I think this is what the art of crafting good code _is_, and something that needs to be the goal of everyone writing software, not something you can say you Just Don't Do because It's Not Your Style.