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
p.s. sorry had to cut out some of the links to the essays I mentioned because I have to earn more than 10 reputation points for that. Just Google them.