"No, it's less effort than that"

Whenever this estimation question comes up, developers rarely put themselves in the shoes of the business side, and try to understand why there needs to be an estimate, and why shorter is always better than longer. What they do instead, is try to protect their holy land of software development, and exacerbate the differences between engineers and "the others" - sarcasm and cynisism usually shine through at this time, and that's how you end up with unrealistic estimations.

I've been a developer, PO, manager, director, CTO, the whole thing. I'm still shocked by how most (not all, but most) developers are simply too disconnected from the reality that, yes, they do need to provide value, and yes, that value does have a time factor. Lucky are we as developers, that people actually ASK us how long it will take, and give us the opportunity to explain it, push back, and actually defend your estimates. The sad reality (at least from 90% of my career), is that developers are rarely able to actually engage in business-level conversations, and actually express their thoughts/ideas/concerns/proposals, in a way that it drives the conversation forward. In a way that helps PMs and managers actually see the complexities of the work, and engage in healthy cost/benefit discussions.

> developers rarely put themselves in the shoes of the business side, and try to understand why there needs to be an estimate

I put plenty of effort into trying to understand. 95% of the time there's no business reason. Most of the time someone just wants to put a number on their powerpoint for some organisational politics nonsense. Sometimes the business wants to decide whether to do thing A or thing B (in which case they have a legitimate need for a relative estimate, but not an absolute one). Occasionally there's a real deadline, in which case again they don't actually need an estimate, they need a "can we hit this date y/n" (or, more usefully, "what do we need to do to make this date").

I'm very happy to work as closely as possible with the business. The reason I'm writing software at all is usually to solve business needs, after all. But when it comes to estimation it really is a case of them being wrong and us being right. (The best businesspeople don't work in terms of estimates in the first place; I don't know if estimates used to work at some point in the past and have been cargo culted since, or what)

> why shorter is always better than longer

If shorter is always better than longer then all my estimates are now 1 day. Does that makes things better?

> Most of the time someone just wants to put a number on their powerpoint for some organisational politics nonsense.

Yes. Thats how coalition-building, budgeting, and reporting works in business. Not saying it should dominate your schedule, but it's just how organizations work. Engineers/Developers are part of the org – not some special snowflakes that are above or beyond politics.

> Thats how coalition-building, budgeting, and reporting works in business. Not saying it should dominate your schedule, but it's just how organizations work.

Nah. Internal competition is a negative for the business. Selfish individuals do it so that they can get better results for themselves. Refusing to take part is the right thing for the business.

I never said it had to be competitive nor is my comment recommending that.

You don’t own 100% of your time when participating in group activities.

> I never said it had to be competitive nor is my comment recommending that.

You said "Thats how coalition-building, budgeting, and reporting works in business." In my experience that's only true in the bad kind of business where there's too much internal competition.

> You don’t own 100% of your time when participating in group activities.

You're responsible for your time. You should share it generously with people who want to put it towards something productive, but you should also push back when people want to waste it.

Internal competition can be good and bad, just like any other management principle. But at the end of the day, an organization needs consensus or it’ll implode, and some people are required to help build that consensus, amongst other duties that extend well beyond product. This is as true for business as it is in any other group dynamic.

You need consensus, sure. You don't time estimates from engineering estimates for it, and even if you did, badgering engineers to make their numbers smaller wouldn't make getting consensus any easier.

You do need estimates to unlock capital, plan budgets, plan for staffing. And badgering engineers to make their numbers smaller is often the result of engineers bullshitting their numbers, as I mentioned before. Engineering departments aren’t free from the same errors or fallacies or biases or mistakes that other humans make.

This is business 101 stuff.

> You do need estimates to unlock capital, plan budgets, plan for staffing.

You might need some amount of estimation. You don't need a full schedule of every task, and producing one just in case is immensely wasteful. In my experience engineers are very happy to help answer questions like "should we be hiring more people for this project" when there is a real need and businesspeople trust enough to share that context.

> badgering engineers to make their numbers smaller is often the result of engineers bullshitting their numbers, as I mentioned before

Pretty sure the causation goes in the opposite direction. Most engineers are honest to a fault; the ones who pad their estimates are the ones who've spent too long working with crappy business people who do things like cutting time off estimates.