"No, it's less effort than that"

Because developing software is almost always an economic activity, and proving maths conjectures almost always isn't.

There is no evidence that you get better economic outcomes from micromanaging software engineers, and not for the lack of trying.

> There is no evidence that you get better economic outcomes from micromanaging software engineers, and not for the lack of trying.

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.

That's yearly planning. If estimation means giving your best effort to complete a project over the next year then that's not a problem. When you start micromanaging on a biweekly basis with daily status updates then it becomes a real problem.

I'm sorry, I can't imagine any business anywhere that would allow all software project estimates to have a precision of "about a year".

We might prefer that our projects be given unlimited leeway, but we still have to fit within businesses and their ability to forecast what they can sell, when the next round of bugs will be patched, and even how many developers should be hired.

Estimated is hard, leadership often fails to understand how hard it is, and it should always be accepted with a bunch of caveats, but it _is_ a very useful tool.

How long does it take to fix a Linux kernel bug? Anywhere from a day to 20 years to never. It's either done as soon as possible, or it's done when it's done and that works for the best software projects.

Estimating is not hard, it's snake oil. That's how you end up paying $100M for burndown charts and a government website that doesn't work.

While thats true, business leaders still need to realize developing software is not the same sort of economic activity as running a horseshoe press or something. Machine can’t just be ran faster. You can’t also just plug another machine in the wall and expect it to know exactly what to do and double your output. Roadblocks often emerge that cannot be foreseen at all short of taking even more time to speculate on these potential blocks down the road.

Certain jobs do have these estimates better managed. For example, tunnel construction often hits unknown things underground that delays the project substantially in time and money. However this is par for the course with tunnel construction and such delays are even expected at this point.

So all custom software should be written with a blank check and an unlimited timeframe?

You're either arguing for something that can not work in commerce or you're not arguing in good faith; I'm not sure which.

You write the check once a year and plan projects no shorter than three months.