Why are software schedules so hard to define?

Question

It seems that, in my experience, getting us engineers to accurately estimate and determine tasks to be completed is like pulling teeth. Rather than just giving a swag estimate of 2-3 weeks or 3-6 months... what is the simplest way to define software schedules so they are not so painful to define? For instance, customer A wants a feature by 02/01/2011. How do you schedule time to implement this feature knowing that other bug fixes may be needed along the way and take up additional engineering time?