Your negotiations at the car dealer are usually based on some source of facts.
Glen B. Alleman
1

Quotes below from Glen B. Alleman:

If you accept that estimates are for business decisions more often than they are for developer decision, then facts are needed for a negotiation to have any mutual beneficial outcome for the business and those provided value to the business in exchange for the cost of that value.

Of course the estimates are for business decisions. I don’t know of any developers that would willingly choose to do estimates unless the business wanted them. But let’s be real clear here. These are estimates. By definition, they require a judgment based on skill and experience. The only facts that are in play pertain to the scope. What’s inevitable is that there’s some scope, and there’s an estimate that’s based on it. It’s a proportional relationship. More scope, bigger estimate. Less scope, smaller estimate. All other things being equal, scope is the only variable that should influence an estimate.

When there is no “basis of estimate” those asking for the estimate have no “basis” on which the judge the estimate provided by those being asked. This is not the foundation for a mutual beneficial outcome.

The fallacious assumption here is that the estimate should be judged. The undercurrent of what you say suggests that every conversation between programmers and business people is rightfully laden with mistrust and suspicion towards the programmers. If that’s the intention, then this isn’t an estimation problem. All other things being equal, if the scope doesn’t change, neither should the estimate. Expecting otherwise suggests that there’s some other hidden variable that can be adjusted to change the outcome. That means either there’s an assumption of slacking, or a failure to understand the harm that overtime causes to both employer and employee. If any other variable besides scope is expected to influence an estimate, adjusting that variable with that expectation is likely coercive and certainly risk-inducing. There is no margin. Scope, and estimate. That’s it.

When the developer says 5 and the asked says “I need 3” AND there is no basis of estimate for either 5 or 3, there is no means to actually negotiate and the results is those paying have the final say.
Until those being ask[sic] come to the table with credible, verifiable, statistically sounds[sic] estimates, this relationship will never change. And those consuming the money from those providing the money need to provide credible estimates. So those providing the many can make credible decisions.

Utter nonsense. “[T]hose paying” are paying for professionals to put a generally understood amount of time (usually, in the US, a 40 hour work week) into solving business problems. They’re not paying to give people stress-related illnesses or for the schedule disruptions they cause, to write ticking time bombs of bad code because devs are fatigued from working long hours, or for slacking off. They’re paying for professionals to do their jobs. A professional in any other field doesn’t succumb to ridiculous pressures like this; it’s unethical. “Sir, your surgery is going to take about 5 hours.” Who, in their right mind, would insist, “Well, doctor, I need it done in 3?” If the logistics coordinator says, “The boat will arrive in 5 days,” he can’t bend the laws of physics because his boss says, “I need it in 3 days.” This kind of unreasonable expectation invites unsafe conditions and risk. While this kind of pressure may make for entertaining TV, it’s a terrible way to write software.

Claiming that the people writing the checks have the final say on the size of an estimate makes the entire process of estimation worthless. “I say how long you think it will take to complete this feature?!” This is toxic. A development team amputating 40% off of an estimate because the guy writing the checks leans on them means that the new, smaller estimate now reflects far more risk.

The mutually-beneficial outcome should be arming business people with the best information possible. A coerced estimate is a fabrication. It’s bad data from which bad decisions get made. It’s bad for the programmers, and it’s bad for the business that’s trying to make decisions based on these falsified estimates. You want mutually-beneficial outcome? Treat your programmers with respect, trust, and professionalism. Stop pressuring for smaller estimates.

A single golf clap? Or a long standing ovation?

By clapping more or less, you can signal to us which stories really stand out.