"No, it's less effort than that"

Thats not really the point that my reply was addressing. Software production almost always takes place within a wider context of economic activity: product launch activities need to be scheduled, server capacity needs to be provisioned, hardware needs to be produced and assembled, people need to be paid out of budgets, etc. I'm a dev and I hate being micromanaged, but usually people really do need to know when the code will be done.

Not so much for mathematicians proving conjectures. Which is nice for them. I guess.

Why don't you? Surely there are ways of granting the required access in your organization?

If the answer is something akin to "not my job", then you have an organization that values intercommunicating pieces each with strict responsibilities. It should be expected that communication completely dominates output performance.

If properly tuned, such organizations can achieve good quality, and if the duties are well specified, also great throughput. But they will never have low latency, as turnaround time is sacrificed for other tings.

The example of a week long estimation for a trivial task is pretty much expected then. In a fully booked schedule, any new task is not likely to be scheduled for weeks. If that task then requires the attention of more than one person, because of the above fine grained responsibilities, those turnaround times really start to add up.

If that's not a good fit for the job at hand, the organization is just not suited for the task.

In real world projects you don't actually know "t", nor do you know how "p" and "n" are conditioned by other factors, nor is there any basis (IMHO) in reality to that "1.3" factor in front of "number of new being used."

It's a pity that in so many orgs people can't just be adults, trust each other, and recognize that work often takes unexpected turns.

Hmmm it doesn’t seem unreasonable in that context? You’re really asking people to work more effectively, to accomplish the same amount of work more quickly.

It’s like asking sales people what their quota should be. They pick a number that is no-brainer hittable, because there is a lot of complexity and many unknown variables in getting deals signed, so to prevent looking bad they’ll pad their number. But their no-brainer number is below what the business needs.

So you tell them their quota is going to be a bit higher. They’ll have to stretch to hit it.

And it’s even MORE important since their comp is DIRECTLY tied to hitting that number.

And yet sales people aren’t writing article after article about how self-set quotas are sacrosanct, should only settable by sales people themselves, and how clueless management is to try to get more performance above the no-brainer target.

Developers will often plan out a cathedral when what’s needed is a garage. Usually this is due to a misunderstanding of the requirements, or an inability of the requestor to formulate or express them. Also, developers are notoriously bad at forecasting work product and the numbers they deliver usually have a tenuous link to reality.

The conversation that starts with “We don’t have 6 months, how do we deliver this by 12/31?” is ultimately a hashing out of what the requirements are. When it’s a cool tech driven story, we call it “an MVP”. When it’s driven by the business, the author considers it yelling at the weatherman.