Let's talk about the reality of software development. Some projects are easy to estimate, especially in domains a developer has tackled before. As an example, consider a developer who has written five static pages who's asked to estimate how long it'll take them to write a sixth. Think of these projects as a well-defined path through the meadow to success. However, some projects are closer to crossing glacier for the first time; you never know when that fluffy bit of snow on the ground is hiding a crevasse of challenges.

While it may be true, saying "it'll be done when it's done" isn't useful. All tasks involve some aspect of uncertainty. Coming up with an at least half-way decent estimate requires a team to break down the problems they're facing into smaller chunks that can be estimated. This is a useful exercise when it comes to prioritizing projects, budgeting, and go/no-go decisions.

There are many ways in which estimation as an exercise can be corrupted. Some people, particularly those who haven't written software themselves, treat all estimates as accurate. In their mind, that "I guess 3 months" estimate a developer gave quickly turns into "I can 100% deliver this to you fully tested, with all of the additions you added along the way in 3 months". This over-indexing often leads to the situation where a developer is disciplined for not meeting expectations, even though they tried their hardest to do so. Some people don't like the estimates they are presented with, so they seek out a lower estimate. They are then shocked when the project takes longer.