I hear what you're saying but my experience is that dwelling in #2 without seeing the bigger picture does very often just as much result in cost/schedule overruns, because shoving certain features or trying to improve certain aspects just collides with the status quo and sometimes cannot be easily accomplished if things are built "wrong" to begin with (wrong often just meaning that they were based on then-relevant prerequisites/assumption which are no longer relevant). Also, the cost of maintenance is often just not taken into account, which means that in the end you have to spend way too much time to shoehorn a half-baked solution into the status quo which has the appearance of delivering what was requested (but doesn't always, because you had to compromise, leaving everybody unhappy) while taking way too much time and at the same time just piling more bloated poo on top of what's already there, making maintenance in the long run even harder. I can't count how many times I've been in a situation where implementing something shouldn't have taken more than 30 minutes but because the codebase was in a not-so-good(tm) state took several days instead. This piles up exponentially, resulting in frustrated developers, a worse product and cost/schedule overruns. In a perfect world, code should improve over time, not deteriorate.