Software time&#x2F;cost estimates are essential.  If I run a business, I need to have some understanding if an investment will have a return.  If I have no way to gauge that at all, then there are many more predictable endeavours where I can spend the money and realize a return.  When you invest, do you simply say the future is unknowable and bet on raw emotion?  I should hope not.  That&#x27;s not to say you may err in your judgment of available facts, you may still lose, but at least you understand some of the parameters about what constitutes success.<p>Software time&#x2F;cost estimates are exactly that: estimates not guarantees.  We tend to think of such things in terms of project management and contract enforcement.  If anything, that is where we go wrong.  What we should do is not try to understand the whole project in terms of an unalterable roadmap, but rather as a guideline for managing expectation and for informing decisions that are made during the course of a project.  I use my estimates to sell the project, yes, but I also tell the client that as we go along we will be making many decisions that will move us away from our initial plan as we better understand both the issues and opportunities a project affords.  Sometimes spending more time than planned will make sense, sometimes it won&#x27;t and we cut the feature.  Sometimes we find that we have failed to identify important features and sometimes we identified a feature early on that isn&#x27;t as important as we thought.  The overall project plan and estimate does set a benchmark to ensure the economics are still correct, after all if we lose that we lose the point of the project entirely, but we don&#x27;t turn that plan into dogma.  We don&#x27;t lose sight of the reason that caused the project to exist.<p>So, yes, we need estimates no matter how hard they are to get accurate.  What we need to stop doing is equating that estimate as an oath to be upheld regardless of what new knowledge comes along.