8 ms·

> Accurate estimates are impossible disagree, not all tasks can be estimated accurately depending on circumstances but this does not imply that it's impossible

> Accurate estimates are impossible disagree, not all tasks can be estimated accurately depending on circumstances but this does not imply that it's impossible to estimate any task accurately.

danenania 3y ago
No matter what the task is, things can go wrong that you didn’t anticipate. Maybe it’s just a quick CSS change, but all of a sudden the webpack build starts mysteriously failing. And now your node_modules got corrupted and oops, when you delete it and reinstall dependencies, there’s a dependency conflict. Once you’ve finally gotten that figured out, some tests are now failing in part of the codebase you’ve never seen before. Better make some coffee… Some version of this can always happen, and as a task gets larger, it is almost guaranteed to happen multiple times in multiple variations. Since you don’t know what problems will arise, there is no way to know how long it will take you to fix them. You can stay up all night in order to pretend that your “quick and easy” estimate was accurate, but that only takes you so far.
- PH95VuimJjqBqy 3y ago
  yeah, and maybe I'll have a heart attack and die while going to take a piss but that doesn't imply it's impossible to accurately estimate that it's going to take 5 minutes for said piss. What if, while cooking dinner, a meteor crashes in my kitchen and so my estimate of 30 minutes to cook dinner turns out to be incorrect? That _obviously_ means the conclusion is that it's impossible to accurately estimate how long it takes to cook that dish so we should never do so. There has to be a name for the type of reply your post represents.
  - danenania 3y ago
    Haha yes, webpack breaking or a test failing is equivalent to having a heart attack or a meteor hitting your kitchen.
    - PH95VuimJjqBqy 3y ago
      if your webpack or ci/cd pipeline is breaking often enough that you worry about it when delivering estimates, that's a you problem.
      - danenania 3y ago
        Are free ponies available in this magical land you speak of where nothing ever unexpectedly breaks? Please put me down for two.
        PH95VuimJjqBqy 3y ago
        you mean the same world where no one has heart attacks and meteors have never hit houses? Both have been documented to have happened, yet somehow you didn't seem to think that should be taken into account when considering estimates for cooking and pissing. If your shit is breaking so often you're afraid to give an estimate, that's a you problem. And yes, we had an internal team that w/i the last 6 months couldn't go a week without a deployment problem. Ask me why they no longer have that issue.
  - OkayPhysicist 3y ago
    Software has an unusually fat long tail, to an even worse extent than real engineering. The probability of something unexpected popping up and inflating the time something takes by an order of magnitude is much, much higher than the likelihood of the same happening while cooking. This ends up coupled with the fact that practitioners (of anything productive) tend to think in terms of 50-ish percentile estimates (i.e., there's a 50% chance this project is done in this amount of time), whereas business people care about 90th-99th percentile estimates. In software, the difference between between a 50th percentile estimate and 90th percentile estimate can be more than an order of magnitude in time spent.
    - danenania 3y ago
      Well said. 50th percentile vs. 90-99th percentile estimates is a great way to put it.
    - PH95VuimJjqBqy 3y ago
      I'm going to repeat what I said to another poster. If your shit is breaking so often it's affecting your willingness to estimate, that's a you problem. I'm driving to another state for the thanksgiving holidays, and I have an estimate for how long that will take. Is it possible when I walk out to my car that the battery died the night before? sure. Am I going to factor such an unlikely event into my estimate? no. Does that imply it's impossible for me to accurately estimate how long that trip is going to take? No it doesn't. Only in software could someone be using a tool that constantly doesn't work and they never consider replacing it or fixing it. Imagine if a carpenter showed up to your house with a hammer whose handle fell off once or twice an hour but they expected you to pay them for the loss of productivity rather than purchasing a hammer whose handle doesn't fall off.
      - OkayPhysicist 3y ago
        Not quite sure how you found your way onto a tech forum without any understanding of what software development entails, but unlike carpentry, where every time you want a new wall the carpenter needs to go through the same process to make the wall, or in cooking, where every time I want a roasted turkey the cook needs to cook a turkey, software almost never does the same thing twice. If you find yourself doing the same thing twice, that's a tool problem. That produces a much fatter tail distribution, because you're doing someone that no one has ever done before, and thus no one knows exactly how long it's going to take.
- arcanemachiner 3y ago
  > Maybe it’s just a quick CSS change, but all of a sudden the webpack build starts mysteriously failing. And now your node_modules got corrupted and oops, when you delete it and reinstall dependencies, there’s a dependency conflict. Once you’ve finally gotten that figured out, some tests are now failing in part of the codebase you’ve never seen before. This is too real.

> Accurate estimates are impossible disagree, not all tasks can be estimated accurately depending on circumstances but this does not imply that it's impossible to estimate any task accurately.

danenania 3y ago

No matter what the task is, things can go wrong that you didn’t anticipate. Maybe it’s just a quick CSS change, but all of a sudden the webpack build starts mysteriously failing. And now your node_modules got corrupted and oops, when you delete it and reinstall dependencies, there’s a dependency conflict. Once you’ve finally gotten that figured out, some tests are now failing in part of the codebase you’ve never seen before. Better make some coffee… Some version of this can always happen, and as a task gets larger, it is almost guaranteed to happen multiple times in multiple variations. Since you don’t know what problems will arise, there is no way to know how long it will take you to fix them. You can stay up all night in order to pretend that your “quick and easy” estimate was accurate, but that only takes you so far.

PH95VuimJjqBqy 3y ago
yeah, and maybe I'll have a heart attack and die while going to take a piss but that doesn't imply it's impossible to accurately estimate that it's going to take 5 minutes for said piss. What if, while cooking dinner, a meteor crashes in my kitchen and so my estimate of 30 minutes to cook dinner turns out to be incorrect? That _obviously_ means the conclusion is that it's impossible to accurately estimate how long it takes to cook that dish so we should never do so. There has to be a name for the type of reply your post represents.
- danenania 3y ago
  Haha yes, webpack breaking or a test failing is equivalent to having a heart attack or a meteor hitting your kitchen.
  - PH95VuimJjqBqy 3y ago
    if your webpack or ci/cd pipeline is breaking often enough that you worry about it when delivering estimates, that's a you problem.
    - danenania 3y ago
      Are free ponies available in this magical land you speak of where nothing ever unexpectedly breaks? Please put me down for two.
      - PH95VuimJjqBqy 3y ago
        you mean the same world where no one has heart attacks and meteors have never hit houses? Both have been documented to have happened, yet somehow you didn't seem to think that should be taken into account when considering estimates for cooking and pissing. If your shit is breaking so often you're afraid to give an estimate, that's a you problem. And yes, we had an internal team that w/i the last 6 months couldn't go a week without a deployment problem. Ask me why they no longer have that issue.
- OkayPhysicist 3y ago
  Software has an unusually fat long tail, to an even worse extent than real engineering. The probability of something unexpected popping up and inflating the time something takes by an order of magnitude is much, much higher than the likelihood of the same happening while cooking. This ends up coupled with the fact that practitioners (of anything productive) tend to think in terms of 50-ish percentile estimates (i.e., there's a 50% chance this project is done in this amount of time), whereas business people care about 90th-99th percentile estimates. In software, the difference between between a 50th percentile estimate and 90th percentile estimate can be more than an order of magnitude in time spent.
  - danenania 3y ago
    Well said. 50th percentile vs. 90-99th percentile estimates is a great way to put it.
  - PH95VuimJjqBqy 3y ago
    I'm going to repeat what I said to another poster. If your shit is breaking so often it's affecting your willingness to estimate, that's a you problem. I'm driving to another state for the thanksgiving holidays, and I have an estimate for how long that will take. Is it possible when I walk out to my car that the battery died the night before? sure. Am I going to factor such an unlikely event into my estimate? no. Does that imply it's impossible for me to accurately estimate how long that trip is going to take? No it doesn't. Only in software could someone be using a tool that constantly doesn't work and they never consider replacing it or fixing it. Imagine if a carpenter showed up to your house with a hammer whose handle fell off once or twice an hour but they expected you to pay them for the loss of productivity rather than purchasing a hammer whose handle doesn't fall off.
    - OkayPhysicist 3y ago
      Not quite sure how you found your way onto a tech forum without any understanding of what software development entails, but unlike carpentry, where every time you want a new wall the carpenter needs to go through the same process to make the wall, or in cooking, where every time I want a roasted turkey the cook needs to cook a turkey, software almost never does the same thing twice. If you find yourself doing the same thing twice, that's a tool problem. That produces a much fatter tail distribution, because you're doing someone that no one has ever done before, and thus no one knows exactly how long it's going to take.
arcanemachiner 3y ago
> Maybe it’s just a quick CSS change, but all of a sudden the webpack build starts mysteriously failing. And now your node_modules got corrupted and oops, when you delete it and reinstall dependencies, there’s a dependency conflict. Once you’ve finally gotten that figured out, some tests are now failing in part of the codebase you’ve never seen before. This is too real.