There are a few problems with that approach. One is that there is rarely a good time to say, "ok, we've proven that this idea works, let's now go back and do it

There are a few problems with that approach. One is that there is rarely a good time to say, "ok, we've proven that this idea works, let's now go back and do it correctly". It's a constant stream of fixes on a system that "already works". Secondly, telling management that a team was able to go fast previously, but is now going to start being slow so that things can be done correctly, is a quick way to be shown the door. This is evidenced by Amazon and that thousand line Java method that's probably existed for 10 years. Finding that time where you're mature enough to switch gears never seems to happen in practice. I now advocate a "cut corners, cut scope, but do NOT cut quality" approach. Unit tests do not take much longer to write - but they pay dividends when it's time to refactor. I'm now back in a startup where the code was written with that "just ship it" attitude. The code is so terrible that it can take days to fix a bug. I can rewrite entire features (correctly) in that amount of time.