4 ms·

This one is my favorite: http://www.quora.com/Engineering-Management/Why-are-software-development-task-estimations-regularly-off-by-a-factor-of-2-3 http://www.q

This one is my favorite: http://www.quora.com/Engineering-Management/Why-are-software-development-task-estimations-regularly-off-by-a-factor-of-2-3 http://www.quora.com/Engineering-Management/Why-are-software...

jacques_chester 13y ago
You can make the argument that this story reveals important features about taking estimation seriously. 1. The author gave a point estimate, instead of a range. 2. The author didn't decompose the task. They took the highest level view and performed a back-of-the-envelope calculation. A closer reading of a differently-scaled map would have revealed many of these delays, giving at least one or two orders-of-magnitude changes in the initial estimate. 3. The author did not seek out historical data or models for this kind of project. Hiking and bushwalking are well-known. There are tables of travel time which can be used to establish a better idea of the outcome. Experienced walkers could have been sought out for their expert judgement of the initial estimate. It is not as good a parable as people make it out to be. The problem was not an unknown or unknowable problem domain. It was due to ignorance of the basics of estimating.
- jkubicek 13y ago
  Your issues are exactly why that story is a great parable for poor project planning.
  - jacques_chester 13y ago
    Absolutely. But it's often trotted out as a parable for why project planning is pointless, or impossible. Which is a very different conclusion to draw.
    - JoeAltmaier 13y ago
      I don't know, in software projects the country is not just unknown but potentially unknowable; no-one may have walked that kind of terrain before. THEN there are no experts, its useless to predict. And diving deeper into the problem may involve actually solving it. That's my issue with software planning. I can often DO the damn project in the time it takes to estimate doing it. What responsible course of action can I take then? Investigate but don't save the code, give the estimate, then go back and type it in? Blow smoke, give an estimate for the deep dive but call it the project?
      - jacques_chester 13y ago
        All estimates are wrong, what matters is improving their business value by making them more accurate. That some estimates will be less accurate due to uncertainty is not by itself a reason to totally abandon estimating. The generalised case of your argument is that estimation is imperfect in all cases, therefore, we must abandon estimation. This is known as the Nirvana Fallacy: "we have a partial, imperfect solution. Because it is not complete and perfect, it is worthless". Even modest improvements in estimate accuracy can have enormous value. By the way, estimating is not planning. An estimate is an estimate. A plan is a plan. They are different things.
        JoeAltmaier 13y ago
        Wasn't talking about uncertainty at all, so I'm not sure why that comment. And no, its not really cool to pretend I said something else so you can debunk that. I'll repeat myself then: the task of diving into a problem to estimate its time is, for many problems, approximately equal to the time to solve the problem. And I honestly have a hard time figuring out a responsible approach in those cases.
        jacques_chester 13y ago
        > Wasn't talking about uncertainty at all, so I'm not sure why that comment. Because you wrote: > in software projects the country is not just unknown but potentially unknowable Which is uncertainty. > I'll repeat myself then: the task of diving into a problem to estimate its time is, for many problems, approximately equal to the time to solve the problem. Non points-scoring questions: does that happen to you often? Can you give an example? How did you know that the time to estimate would be equivalent to time to implement? I agree that estimates themselves have a cost/benefit ratio and that sometimes it is going to be negative.
        JoeAltmaier 13y ago
        I write in C++. Estimating can require prototyping classes and methods; this IS development, often all that is needed to deploy. E.g. I'm being asked to estimate the time for an audio-monitoring feature to play a tone when someone speaks yet their voice is muted in the space (Sococo Teamspace has spaces where people work together). The voice-level feature is already in place; its being used by the mic-selection dialog. So the whole estimate involves showing the GUI engineer the API he's already using. I have to fill out forms online, define the 'feature', time-box development and keep this record up-to-date as the work progresses. OR I just doorbell Tom and say "Tom, use the same API as the mic-selection dialog". In fact, its taken longer to type this message than the fake work I have to do for this. So that's a degenerate case. Other cases involve changing timers for idle connection probing (done before the request was finished being uttered); investigating silent-participant overhead (which I did during the sprint planning meeting using netmon on the idle participants in that meeting); aggregate audio packets via our media node to reduce router overhead for bursts of UDP. That last one is illustrative. To make the estimate I reviewed the media send path for the right place to put in the code (half an hour). Then decided the transport layer was ideal place to aggregate packets using a Nagle timer. I identified 5 cases (idle; aggregate packet under construction; oversize packet; normal packet to aggregate; normal packet that blows the aggregate limit). The constructors for packets need changes to allow header extensions to identify the aggregation boundary for unpacking. That took a couple of hours. Plus the time to enter the tickets and put in the estimates. The work will take a few minutes, since I have identified everything that will need to be done. The 'estimation' process has dominated the project time. I can be done with the project before the project manager even notices the tickets I've entered into the database! SO the whole estimation/recording process is some silly circle-jerk to make management feel involved. IT wasted my time, delayed the project and kept me from doing more useful tasks that our customers could really benefit from. Btw sorry for my snarky tone above; I was in the middle of this sorry process when I resorted to reading HN/commenting to let off steam.
kevando 13y ago
I've used this analogy several times. It really gets the point across to non-devs.

jacques_chester 13y ago

You can make the argument that this story reveals important features about taking estimation seriously. 1. The author gave a point estimate, instead of a range. 2. The author didn't decompose the task. They took the highest level view and performed a back-of-the-envelope calculation. A closer reading of a differently-scaled map would have revealed many of these delays, giving at least one or two orders-of-magnitude changes in the initial estimate. 3. The author did not seek out historical data or models for this kind of project. Hiking and bushwalking are well-known. There are tables of travel time which can be used to establish a better idea of the outcome. Experienced walkers could have been sought out for their expert judgement of the initial estimate. It is not as good a parable as people make it out to be. The problem was not an unknown or unknowable problem domain. It was due to ignorance of the basics of estimating.

jkubicek 13y ago
Your issues are exactly why that story is a great parable for poor project planning.
- jacques_chester 13y ago
  Absolutely. But it's often trotted out as a parable for why project planning is pointless, or impossible. Which is a very different conclusion to draw.
  - JoeAltmaier 13y ago
    I don't know, in software projects the country is not just unknown but potentially unknowable; no-one may have walked that kind of terrain before. THEN there are no experts, its useless to predict. And diving deeper into the problem may involve actually solving it. That's my issue with software planning. I can often DO the damn project in the time it takes to estimate doing it. What responsible course of action can I take then? Investigate but don't save the code, give the estimate, then go back and type it in? Blow smoke, give an estimate for the deep dive but call it the project?
    - jacques_chester 13y ago
      All estimates are wrong, what matters is improving their business value by making them more accurate. That some estimates will be less accurate due to uncertainty is not by itself a reason to totally abandon estimating. The generalised case of your argument is that estimation is imperfect in all cases, therefore, we must abandon estimation. This is known as the Nirvana Fallacy: "we have a partial, imperfect solution. Because it is not complete and perfect, it is worthless". Even modest improvements in estimate accuracy can have enormous value. By the way, estimating is not planning. An estimate is an estimate. A plan is a plan. They are different things.
      - JoeAltmaier 13y ago
        Wasn't talking about uncertainty at all, so I'm not sure why that comment. And no, its not really cool to pretend I said something else so you can debunk that. I'll repeat myself then: the task of diving into a problem to estimate its time is, for many problems, approximately equal to the time to solve the problem. And I honestly have a hard time figuring out a responsible approach in those cases.
        jacques_chester 13y ago
        > Wasn't talking about uncertainty at all, so I'm not sure why that comment. Because you wrote: > in software projects the country is not just unknown but potentially unknowable Which is uncertainty. > I'll repeat myself then: the task of diving into a problem to estimate its time is, for many problems, approximately equal to the time to solve the problem. Non points-scoring questions: does that happen to you often? Can you give an example? How did you know that the time to estimate would be equivalent to time to implement? I agree that estimates themselves have a cost/benefit ratio and that sometimes it is going to be negative.
        JoeAltmaier 13y ago
        I write in C++. Estimating can require prototyping classes and methods; this IS development, often all that is needed to deploy. E.g. I'm being asked to estimate the time for an audio-monitoring feature to play a tone when someone speaks yet their voice is muted in the space (Sococo Teamspace has spaces where people work together). The voice-level feature is already in place; its being used by the mic-selection dialog. So the whole estimate involves showing the GUI engineer the API he's already using. I have to fill out forms online, define the 'feature', time-box development and keep this record up-to-date as the work progresses. OR I just doorbell Tom and say "Tom, use the same API as the mic-selection dialog". In fact, its taken longer to type this message than the fake work I have to do for this. So that's a degenerate case. Other cases involve changing timers for idle connection probing (done before the request was finished being uttered); investigating silent-participant overhead (which I did during the sprint planning meeting using netmon on the idle participants in that meeting); aggregate audio packets via our media node to reduce router overhead for bursts of UDP. That last one is illustrative. To make the estimate I reviewed the media send path for the right place to put in the code (half an hour). Then decided the transport layer was ideal place to aggregate packets using a Nagle timer. I identified 5 cases (idle; aggregate packet under construction; oversize packet; normal packet to aggregate; normal packet that blows the aggregate limit). The constructors for packets need changes to allow header extensions to identify the aggregation boundary for unpacking. That took a couple of hours. Plus the time to enter the tickets and put in the estimates. The work will take a few minutes, since I have identified everything that will need to be done. The 'estimation' process has dominated the project time. I can be done with the project before the project manager even notices the tickets I've entered into the database! SO the whole estimation/recording process is some silly circle-jerk to make management feel involved. IT wasted my time, delayed the project and kept me from doing more useful tasks that our customers could really benefit from. Btw sorry for my snarky tone above; I was in the middle of this sorry process when I resorted to reading HN/commenting to let off steam.

kevando 13y ago

I've used this analogy several times. It really gets the point across to non-devs.