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?
If you are cranking out a project nearly identical to other projects you have done, using familiar tools and a familiar team, and you are given firm, written requirements, then it should be possible to make good estimate.  

These are the conditions that painters, carpet installers, landscapers, etc., regularly experience.  But it is not a good fit for many (or most) software projects.  

We're often asked to estimate projects that use new tools, technologies, where requirements are changing,etc. This is more extrapolation into the unknown than interpolation over our past experiences.  So it is natural that estimation will be more difficult.
