In the real world its an art, not a science. Despite what many people will tell you, building software is not the same as building houses, and things won't work out if you try to use the same estimating techniques.
As a rule we estimate at least two different ways, with at least 2 people. The closer the estimates are, the closer to reality they are likely to be. If they are too far apart, we find out why.
Do not micro estimate - at some point your estimates become just numbers used to create an illusion of accuracy, initially it keeps managers happy, but soon it becomes a stick he will weld over you. In most cases, estimates add limited value to the business. My experience is the job will get done no matter what the estimate is, the amount paid should be based on value added, not cost plus, and no software engineer should be working on a job where cost plus is close to value add. Further, I have never seen a software engineer get "paid" for the time he is estimating the next thing, he is usually expected to slip it in in spare time, usually at the end (busy) stage of a project. Therefore, rather than spend obscene amounts of time estimating, give the manager a few numbers and get on with the work.
We do not use estimates for scheduling, that's one of the biggest and most common mistakes you can make. Estimates are just one of many inputs into the scheduling tool.
Re estimate at key milestones.
Estimates are not quotations.
I live by the rule "I do not negotiate my estimates, I will willingly negotiate my charge out time, quality and feature set". I state it clearly and repeatably when required (It's a bit more politically correct in front of customers.).
Read the works of Steve McConnell (construx.com)