Programmers are bad at estimates for one main reason: Many think that to stay employed they must give the answer the manager or client wants to hear and often that number is way too low.
I've done some work at a customer where they used Planning Poker. I'm guessing the idea comes from some Agile development or Extreme Programming methodology. I'm not a fan of the latter, but Planning Poker was entertaining and seemed like it had some good points.
The team sits together, everyone has a deck of cards with values. The team lead calls out a task and everyone throws down his estimate at the same time. If the values diverge widely, the team lead asks the outliers to explain, and everyone can reconsider after the explanation. The highest remaining number is taken as the estimated time.
This was done in days for big tasks, who where then split up in sub-tasks where the same was repeated in hours.
Sharing the responsibility of estimates prevents the manager-pressure problem you talked about. If the team estimates it takes 5 days and the manager thinks it should only take 3, the team isn't going to back down (unlike what could happen in 1-1 conversations), and the manager will ignore the estimate at his own peril.
Planning Poker helps, but a few caveats must be recognized:
Some people have little, or no, idea the effort required for a task. Fair enough, just don't base plans on known ignorance. Compelling them to vote is silly.
Some people have differing notions of "done". One self-appointed hotshot may be able to crash thru the code and make something run happy path in a few hours and thus gives a low estimate, but unlike others fails to account for ripple effects, breakage, documentation, consulting with others, etc. Are votes for "it works"? or "everything related is completed"?
All too often outliers are right, but dismissed because they're outliers and given just a few impromptu seconds to explain complex nuances why they're right and the disinterested opposition is wrong. Subsequent "I told you so"s much farther down the road are disheartening, and kept quiet as the opposition still doesn't see the connection nor want to.
Again, make sure the estimate includes all related work. Implementation may be quick; integration testing or documentation may be long. Don't give something a 3 to do and ignore the additional 5 needed for ripple effects.
THe team quickly learns what everybody is going to say for each part of the estimate, and they all throw down the same card. Nobody wants to spend any more time in the meeting, and throwing down an outlier means thinking hard and explaining yourself.
If you work in an environment where everyone has respect for one another, that sounds like a great solution. If not and it's the manager's way or the highway, then that doesn't work so well.
As Atwood notes, planning poker is a variant of a technique called Wideband Delphi, which McConnell found in some studies he ran to measurably improve estimate accuracy.
The most important difference is that fully dressed Wideband Delphi provides anonymity to the estimators. The goal is to avoid allowing estimation to become a venue for status play or kabuki theatre.
As pointed out in the comments on the article page - programmers are actually pretty good at estimating.
They are very bad at defending their estimates, though, and are often forced to adjust down unrealistically. Which raises the question - why ask for the estimate in the first place. And the answer is "to have a scapegoat"
The manager gets credit for success, and the developers get the blame for failure.
