[dustingetz]

i would add that the reason no product manager wants to pay for #3 is because historical attempts to do so have overwhelmingly resulted in cost/schedule overruns; did-not-finish outcomes are common. Let he who believes otherwise demonstrate so with his own money, this is called a startup and note that virtually all startups fail i.e. run out of some critical resource without finishing! So what is a wisened product manager to do? No easy answers here - simply look to the industry to see what the average outcome is. And it is not for lack of trying. in my opinion software delivery is not a solved problem. but it is really hard to make money as a software delivery expert by going around and saying that you don’t know how to deliver software.

[bonki]

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.