2) A lot of developers really hate committing to any kind of estimate because they're really just not that good at estimating for a variety of reasons and getting stuck in a commitment that turns out to be unrealistic really sucks.
3) In my experience a good portion of orgs really are bad at business-engineering interactions and end up in adversarial relationships like you're talking about where engineering is seen as "those guys that refuse to commit to any deadline and suck at communicating status I can plan around" and the business owners are "those guys who don't understand what they're asking for and are constantly trying to micromanage to get blood from a stone". Also in my experience, neither side is entirely innocent in these situations.
In development (as opposed to production) I personally fight against any commitment if it comprises the "what" as well as the "when".
You fix the date of the next release and provide me with a prioritized list of bug fixes and features to work on? Nice, let me start to work!
You think that a specific new feature could improve our sales and you let me drop anything else and call you back as soon as I have any news? Wonderful, I'm already analysing the issue in my head!
Anything else, and I'll let you know that your dreams are not likely to come true.
[1]: https://en.wikipedia.org/wiki/Project_management_triangle
That's sales guy talking.
From my point of view, he is not a customer! A customer is someone who buys the product we currently have ready to sell, or someone who pays for customization.
2) Except I have seen multiple times when customers paid for customization, then jumped ship (and demanded a refund) because that same customization took too long.
There is a reason that product owners need to be able to say, "No" and be good at managing expectations. Otherwise they end up with an unmanageable backlog, broken promises, and sometimes will scapegoat the engineering team. That isn't too say over promising doesn't happen on the engineering side of the equation. But the product owner is the individual ultimately responsible for all feature work promised.
If those projects have to be pushed back, the only explanation is that they were started too early.
Why not ask that question instead of guestimating individual tasks ?
I think people loathe estimations because they are never the end point, only an input data to derive a result that people don’t want to let them decide directly.
It can be legitimate to not have your engineers decide of the roadmap, but you can’t fault them for feeling abused when you’re not asking the real questions.
Why should you burn yourself out just to do an arbitrary number of tasks, based on wildly inaccurate estimates, just to meet an artificial sprint deadline?
The whole activity of estimation, planning and reviewing is often just a way to implement micromanagement.
What is the benefit? It pushes engineers to spend 100% of their time on urgent tasks and stop doing any learning, exploration of new ideas, discussing alternatives, socializing.
[Over]committing creates a constant sense of urgency that leads to higher productivity in the short term. Unsurprisingly, it's a source of burnout.
I used to work for an organization where engineers so universally loathed the idea of estimates that I was convinced that it was just a necessary evil. But a few months ago I joined an organization where the relationship between engineering (which I'm in) and business is not very adversarial. Here, estimates are a tool to answer the question "how much work should we take up in the next sprint without burning ourselves out?". The estimation process is not loved, but it's not hated either.