To grasp why (time based) software estimates are hard we need to do some thinking on the nature of software development.
The difference between manufacturing activities and design work is probably the most important concept business people need understand. During the industrial era there was a sharp distinction between design and manufacturing. We designed blueprints that were reproduced in a factory as many times as we wanted.
We are applying that same model in our heads to the software development process, we assume that first someone has to design the product after which different people manufacture it. Once you start thinking about when the design phase ends and when manufacturing starts, you realize this doesn't apply to software development. Consider the following representation of a product development cycle:
... => design => (blueprint) => manufacture => (product) => ...
Intuition might tell you that translates to software development like this:
... => design => (Interaction design deliverables) => manufacture => (Source Code) => ...
While in fact it's more like this:
... => design => (Source Code) => manufacture => (Software application) => ...
In other words: The source code is the design not the product! Manufacturing software is completely automated (compiling the source). Others have explained this far better than i can, I would recommend you read this essay by Jack Reeves: What is Software Design?
The difference between design and manufacturing is not just a conceptual one and has some very real implications for the way we manage software development. Design work is by nature highly unpredictable and depended on individuals while manufacturing is much more predictable and depended on resources.
From this line of thinking follows that variation of individual productivity among developers is so high that it's impossible predict how much someone can produce in a certain amount of time. For more insights on this, check out the following essay by Paul Graham: How to Make Wealth.
There are many more implications of the 'design != manufacturing' way of thinking. Another important one is the fact that you never set out to design something that's already available. This adds to the amount of uncertainty in development work.
Combine these with the many reasons business people pressure developers into lower estimates, plus the fact that people have a hard time estimating absolute measures and you got your self a recipe for highly inaccurate estimates.
If your Sales Manager still has doubts, this article might clear it up:
Fingers in the air: a Gentle Introduction to Software Estimation
...software development community has a very poor record in estimating anything—in fact is very common for projects to run over-time and over-budget, and deliver poor quality products with fewer features than originally planned.
Part of the problem is that software is quite difficult to estimate. In fact, huge differences in individual productivity, the fact that creative processes are difficult to plan, the fact that software is intangible, and the fact that during the life of the project anything can change - e.g., scope, budget, deadlines, and requirements—make software estimation a challenging task.
However, in my experience, the main cause of poor estimates is that the various stakeholders are often unaware of what estimates are for, and what they should look like. This lack of knowledge means that they have no way to judge if the project goals and the associated expectations are realistic. The result can be either overestimation which causes the allocation of an excess of resources to the project, or, more often, gross underestimation which often leads to "death march" projects [You], which are characterized by "project parameters" that exceed the norm by at least 50%, e.g.:
- The schedule has been compressed to less than half the amount estimated by a rational process
- The staff is less than half it should be in a project of the same size and scope
- The budget and resources are less than half they should be
- The features, functionality and other requirements are twice what they would be under normal circumstances
The rest of the article is an introduction to the software estimation process aimed at project managers, developers and customers who want to get a better understanding of the basics this subject, and avoid to make their projects a death march one...