Even in my own work, when I'm moving back and forth across the code, I'll set up interfaces and contracts where appropriate, because it's important to have stab

Even in my own work, when I'm moving back and forth across the code, I'll set up interfaces and contracts where appropriate, because it's important to have stability somewhere in the evolving mess. One of the problems you can run into while free-range programming is chasing the consequences of a change back and forth, where a fix in one place requires a fix in another, requiring a fix in another... When I mentor coders one of the core lessons I try to get them to internalize is to code from known working state to known working state. Always be able to run something, either the code or a unit test, so that you know it works as expected. Add some code and get to the next known working state. This requires no undefined dependencies. If you're suddenly in a position where you're saying "I don't know why this doesn't work", you've bitten off more change than you can handle and need to back up and stabilize by decomposing the working state you're aiming for. Interfaces and contracts help immensely with that as long term stable scaffolding, as a skeleton for your codebase.