5 ms·

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.

andyjohnson0 3y ago
Because developing software is almost always an economic activity, and proving maths conjectures almost always isn't.
- ResearchCode 3y ago
  There is no evidence that you get better economic outcomes from micromanaging software engineers, and not for the lack of trying.
  - andyjohnson0 3y ago
    > 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.
    - ResearchCode 3y ago
      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.
      - NegativeK 3y ago
        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.
        ResearchCode 3y ago
        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.
        NegativeK 3y ago
        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.
        ResearchCode 3y ago
        You write the check once a year and plan projects no shorter than three months.
- kjkjadksj 3y ago
  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.
gardenhedge 3y ago
Estimates help planning. The problem is that they often travel through a company and become immovable deadlines.
- ResearchCode 3y ago
  Planning too often is also a problem. You should not do it more often than every three to six months.
  - gardenhedge 3y ago
    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.
latency-guy2 3y ago
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.
- ResearchCode 3y ago
  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.

andyjohnson0 3y ago

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

ResearchCode 3y ago
There is no evidence that you get better economic outcomes from micromanaging software engineers, and not for the lack of trying.
- andyjohnson0 3y ago
  > 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.
  - ResearchCode 3y ago
    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.
    - NegativeK 3y ago
      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.
      - ResearchCode 3y ago
        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.
        NegativeK 3y ago
        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.
        ResearchCode 3y ago
        You write the check once a year and plan projects no shorter than three months.
kjkjadksj 3y ago
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.

gardenhedge 3y ago

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

ResearchCode 3y ago
Planning too often is also a problem. You should not do it more often than every three to six months.
- gardenhedge 3y ago
  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.

latency-guy2 3y ago

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.

ResearchCode 3y ago
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.