"No, it's less effort than that"

Why are you pushing software engineers for "estimates"? You don't ask mathematicians how long that conjecture will take to prove. It's done when it's done.

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.

Estimates help planning. The problem is that they often travel through a company and become immovable deadlines.

Planning too often is also a problem. You should not do it more often than every three to six months.

> 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.

Hello waterfall my old friend. How have you been doing?

But seriously.. there's levels to planning. There's strategic planning which is less often and then implementation of delivery stages which is more on going. It is helpful to know if something will be delivered in 2 weeks or 2 months. The problem is when the dev team says 2 weeks but discovers more and knows it will be 6 weeks but the deadline is firmly set to the initial 2 week estimate.

Probably because software engineers are not mathematicians. Also, you're not doing foundational research or breaking away at the edge of human knowledge either. Similarly, mathematicians are not immune to deadlines either.

Software engineers are not assembly line laborers developing x cogs per hour either. There is no evidence that micromanaging software projects works.

Tenured mathematicians are immune to deadlines, and non-tenured ones don't "story point" conjectures. Your PI does not usually make you submit daily status reports. Targeting a submission date three to six months ahead and trying again if it doesn't work out is a framework that would work in software engineering too.

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.