For myself, I find the most important thing is to have clear interfaces (contracts). That is, I can write the hackiest code inside of a module, but I will spend time upfront to make sure that what that module exposes is the cleanest I can make it.<p>Then, I can isolate and fix a function by itself. It may have been written to be 200 lines long, filled with hackery and half measures, but my complexity is contained within it, and the functions it calls out to (so nothing calling it should need to be substantively changed). Those called functions, in turn, may also need improvements, but my focus every step of the way was keeping the interfaces clean, so I can always get down to some base set of functionality that has no dependencies, fix that up, make the necessary fixes to keep things working in the functions directly calling them, test, and then move up to those calling functions and repeat, until I get back up to the big ugly 200 line monstrosity. Every step of the way I can  make sure things are still working, and I don&#x27;t have to substantively touch anything above the 200 line monstrosity until I&#x27;ve cleaned it up.<p>So by keeping my interfaces clean, I can figure out how, inductively, I can make progress.<p>The lack of clear interfaces is the real problem; if you don&#x27;t put in the effort when writing your code to keep those clean, you end up with circular dependencies, implicit workflows and state between functions (&quot;to call X you first have to call Y to get a foo, pass that into X, then call Z to reset the foo value&quot;), and other nightmares, that move you more to needing a full rewrite.