A great/concise treatment of this can be found in this web article on "Heussler on Leadership": http://www.csis.gvsu.edu/~heusserm/articles/NeverTwoWeeks.htm

He does an excellent job of arguing that developers and managers have different definitions of "done".  This can cause developers to estimate only a small portion (1/6th according to some) of the effort.  Traditionally, developers tend to think of "done" meaning "it's coded and *seems* to work".  Management thinks of "done" meaning it's coded, tested, and is of production-grade quality. -- EricKramer

----

A counter to this is that often management like to take the test phase out of a schedule, so that the developer's definition of ''done'' is all that gets done.

----

One problem is that developers ''can't'' give an estimate of how long it will take to get something into the hands of customers.  A developer might be able to estimate the coding and debugging time, but a developer cannot estimate how long it will take for QA to certify it, how long it will take the tech writer to update the docs, how long it will take manufacturing to create the CDs, how long it will take to coordinate with the customers to get the new version installed, how long until the users use the new version and find problems, etc.  Getting all these estimates together is management's job, and managers shouldn't blame developers for giving "bad estimates".

I've always thought that programmers are ''required'' to be optimists, because we'd all quit if we had a realistic notion of how bad upcoming work is going to be.  This is an important mind-shift that is required of a DeveloperTurnedManager, who has to be pessimistic to be an effective manager. -- KrisJohnson

----

We now have a template of a programming task that explicitly names phases:
* Coding till it seems to work
* Fixing it when someone else uses it
* Making the users manual agree with what it does
* Running it on more than one machine
and a few others. We get programmers to write in how long they think the first task will take and then estimate the others as about the same. We've found that the programmers are now estimating longer times than they did, but are anticipating more of the work. By measuring this and accounting for it our estimates are improving.

I further relate this to the estimate in MythicalManMonth and quoted in the article referenced above.
* 1/6 time spent coding
* 1/3 time spent debugging
* 1/4 time spent on local testing
* 1/4 time spent on integration testing

It all comes down to a complete mis-match between the language used and expectations held by managers versus programmers. Making it explicit helps, a lot, although as so often happens, measurement is key.