- He doesn't know how - He doesn't understand how estimates fit into the process of business and managerial finance of product or service development. He looks for existing examples and just sees bad examples.
- He doesn't understand why estimates are needed - He doesn't understand the impact on the business for not knowing how long, how much, and what will be produced for the time and money. These are scarce resources and decision making in the presence of scarce resources is called Microeconomics. Add uncertainty to these resources and it's still called Microeconomics. Those assigned to estimate do not relate to cost, schedules, or resources that drive the business and the decision made by the business by those estimates.
- He'd rather be doing something else - He would rather be coding. There is a strong tendency to jump from some high-level functional notion of what the software should do to the coding, without further definition of the effort and duration to do that coding. Coding work is much more fun than making estimates, documenting the requirements, writing tests.
- He sees no reward in it - He doesn't care. No matter what estimates he makes, he will be battered by management and those who could not or would not take the time to participate in the development of the estimate. There is no reward for doing a good job.
All of these and more have NOTHING to do with the principle of making decisions in the presence of uncertainty. That is still in place.
