[patja]

Developer estimation improves when the developer is estimating the time for a task that is repeatable and they have experience or data on how much time the task took in the past. Substitute any title for "developer" in the previous statement and it remains true: civil engineer, drywall installer, plumber, etc.

The challenge is that relatively few developer tasks are highly repeatable, and very few developers are disciplined about collecting data on how long similar tasks required in the past. Also high performing developers get bored easily and frequently want to chase the new shiny tool/framework, where they have no past experience or data to rely on for estimating.

A first question in asking a developer about their estimate is "have you done this type of task before with the same technology you are planning to use". If no, disregard any estimates.

You can get good estimates for high volume of task teams, like maintenance or break/fix teams where the technology remains relatively static from one work iteration to the next, and the work items can be bucketed into meaningful and consistent sizes (T shirt sizing or what have you). Those are typically where you have your junior (or offshore) developers staffed as they pay their dues, and they can benefit greatly from having discipline around collecting data on their actual experience and using that data to reduce variance in estimates vs actuals in the future. This is also a great space for a new dev lead or manager to cut their teeth on managing the consistent collection and application of this data to reduce variance to plan.

For the really fun work though, where your high performing developers want to be operating so they can thrive and experience self-actualization (see Maslow), forget about the estimating angst and just timebox them or go agile -- build something, release it, refactor it, repeat. Don't waste your time creating the illusion of certainty about the future when you have nothing but optimistic gut feel as input to the estimating machine.