Yet if I ask you how long it takes to buy icecream in Japan, based on your experience grabbing milk in the US, your guess will be "less than half a day". Which is good enough for me.
I’m kidding, of course. It really depends on how well business and development understand each other.
Yup. This is the crux of the whole issue, and it's being completely blown out of proportion. There's always going to be details the estimator (dev) won't know, but the more clear a picture you have in your head, the more confidence you can have in an estimation.
This is directly related to the size of the project too, of course. If it's a 12 month project, a single developer is massively unlikely to have a reasonable understanding of all the potential roadblocks that the project will take. However a 1 day task, with tools you know/etc, you can have a pretty good idea how long it'll take.
There's always some unknowns, but that's literally what an estimate is for - attempting to plan for the unknowns. I can write an add function and I'd bet a lot of money that it won't take more than a day.
Unreasonable management seems to be giving developers PTSD here. As I'm having trouble understanding why the idea of an estimate, by definition exactly what we're doing, somehow doesn't apply to software development.
If you're being pedantic you could say the same about a lot of things. How long to dig a 1foot hole in open ground? Well who knows, there might be a massive rock - but that doesn't mean you can't give an estimate. It's literally what an estimate is for, an approximation based on assumptions and expectations.
It's inexperience all around. Also, most places have no clear long term track, so people bounce after 2 years rather than growing to understand each other.
Managers are generally free to cut estimates in half, and move to a new role or move to a new organization when things fall apart. They're not trying to be villains, they have a lot of pressure coming from a lot of directions and think that estimates are bogus anyway, thanks to star trek and the occasional miracle that happens. (sometimes things really are much easier than they seem)
Developers are optimistic, wildly underestimate, and feel bad when they miss them. The overreact and start massively overestimating. When they progress to the next stage they take the time to give a good thorough estimate to have it slashed by a manager, who knows they overestimate.
Nobody sticks around long enough to really understand the state the other is in, so you get this vaguely Kafkaesque world that makes everyone a little crazy.
Software isn't like building a bridge; it's like planning to build the bridge.
I'm pretty good at software estimating; I can roughly tell when something will take an hour, 2 hours, 4 hours, a day, a week, or month, 3 months, or 6 months -- in those intervals. It's more difficult and time consuming to get more specific than that.
I've also had a 1 day task blow out to entire week more than a few times. At that point, you have to start questioning the predictive value of estimates.
If I estimate a month to build your feature and it takes me a year or two, you're not going to be very happy...