←back to thread

388 points replyifuagree | 1 comments | | HN request time: 0.247s | source
Show context
ResearchCode ◴[] No.37966699[source]
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.
replies(3): >>37966719 #>>37966750 #>>37969658 #
andyjohnson0 ◴[] No.37966719[source]
Because developing software is almost always an economic activity, and proving maths conjectures almost always isn't.
replies(2): >>37966726 #>>37968283 #
ResearchCode ◴[] No.37966726[source]
There is no evidence that you get better economic outcomes from micromanaging software engineers, and not for the lack of trying.
replies(1): >>37966928 #
andyjohnson0 ◴[] No.37966928[source]
> 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.

replies(1): >>37966982 #
ResearchCode ◴[] No.37966982[source]
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.
replies(1): >>37968095 #
NegativeK ◴[] No.37968095[source]
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.

replies(1): >>37968146 #
ResearchCode ◴[] No.37968146[source]
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.

replies(1): >>37970584 #
NegativeK ◴[] No.37970584[source]
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.

replies(1): >>37972791 #
1. ResearchCode ◴[] No.37972791[source]
You write the check once a year and plan projects no shorter than three months.