The OP is correct if you do not have clearly defined goals for the project, and it is a field that you have not really worked in before. This is probably true o

The OP is correct if you do not have clearly defined goals for the project, and it is a field that you have not really worked in before. This is probably true of some start-ups. However, if you are working for an engineering company, often you have projects that were similar which can provide a guideline for the scope of the software or software modification that you are undertaking. I would posit that for the majority of software projects, the invention hypothesis cannot be true, because you are not really inventing anything new. You are more likely replacing something that is done manually or done via a hideous and error prone excel spreadsheet machinations. So my complimentary hypothesis is that estimating the budget for a software project is a social issue. Example: My manager and I come up with some really cool feature that will let us market our product to new people. My manager asks me for a time estimate. He says: >How long do you think this project would take for you to do? Basically, it is a simple question that is also completely overloaded with little details, philosophical questions, and other minutia. I can give an estimate of how long it will take for me to get this project done. But how long a project will take me is a derivative measurement. It is units of software engineering multiplied by my units of software completion rate. What we really want is units of software engineering work. This does not exist. You can't invoice for 10,000 ml of software engineering. The punchline for this is that my rate of completion will be different from Steve or Charlie's and we don't have the rate or the units, just the aggregate for any given project. And it seems to be that the tendency is to go to your best programmer to get an hours estimate, rather than your mediocre programmer, regardless of who will be working on the particular project (you probably don't know who will be working on it when you are figuring out financials for a project that is 6-10 months off). There is no standardized software engineering test that gives you a baseline for probable programmer efficiency/ability so that you can adjust the budget of the project accordingly. There are also questions about 'what is done', interruptions from other projects that you have going on simultaneously, interpretation of various details in your spec. And there is other bureaucratic stuff. I've had it where I was budgeted for a few months and had a delivery date representing that, and I hadn't received the relevant input documents that I needed to complete the project 2 months into the timetable. Or the other version, you budget for a few months and some know-nothing pushes back and tells you do not need that much time (or really that his financials will look better if you finish it this quarter rather than next). There are certain unsolved problems in computer science that you may encounter. When asked to solve them as part of my day job, I prefer to gracefully decline and offer a solution that I know has a chance of working and being implemented in a reasonable amount of time (by doing some research beforehand and figuring out what is reasonable within current technology/knowledge and what is pipe-dream/'interesting research' material). There may be things that you do not yet fully understand when working on a project. But it is possible to estimate how long it will take you to learn those things. It is very difficult to estimate the complications of many of the social factors. If stupid steve is working on the project, instead of me, it might never get completed. If a jackass up the chain of command cuts my budget halfway through, i can't predict that. If I get pulled off onto an emergency project, who knows what will happen. I think this is the real reason why startups and small workgroups do so much better at software. By reducing the number of people involved, you reduce the chaos factor and the amount of damage control you have to do due to someone monkeying with your project when they really shouldn't be.