There's an interesting post over on the Hut 8 Labs blog looking at overconfidence in developers and how it effects their estimations of the time it takes to get things done.

I’m going to talk today about what goes on in inside developers’ heads when they make estimates, why that’s so hard to fix, and how I personally figured out how to live and write software (for very happy business owners) even though my estimates are just as brutally unreliable as ever. But first, a story.

He talks about one of his own experiences about overconfidence and how he found a connection point in a section of a book with it as it talked about overconfidence. He talks about why you (we, as developers) suck at making estimates and how it should be less of a "how long to do it" question and more of a "how confident am I that I can do it" question. He points out that there are some situations where estimations don't suck - 0-12 hour tasks.

So what do we do? Just accept that all our projects are doomed to failure? That we’ll have poisoned relationships with the rest of the business, because we’ll always be failing to meet our promises? The key is that you first accept that making accurate long-term estimates is fundamentally impossible. Once you’ve done that, you can tackle a challenge which, though extremely difficult, can be met: how you can your dev team generate a ton of value, even though you can not make meaningful long-term estimates?