3 ms·

So the author of this has a vested interest in their "solution" being the correct one, but I fundamentally disagree with it. I agree with their hypothesis that

So the author of this has a vested interest in their "solution" being the correct one, but I fundamentally disagree with it. I agree with their hypothesis that we are bad at planning/estimating, but the solution is not spending more time on it, but rather less. Firstly I really like this humorous look at the problem: https://www.quora.com/Why-are-software-development-task-estimations-regularly-off-by-a-factor-of-2-3/answer/Michael-Wolfe https://www.quora.com/Why-are-software-development-task-esti... You cannot estimate what you don't know, and you don't know what you don't know and no amount of upfront planning will surface those. In their own example, you can't know upfront that there is a road closed or an accident or that only one cashier is working until you get to that point. In my opinion the most reliable solution is to break the work down into small pieces that deliver value (ideally less than a week's work). Prioritise and then deliver the first piece. Have regular reviews/checkpoints with stakeholders to decide whether any value was delivered, are there new learnings that we need to apply to the rest of the project, or indeed new 'pieces' that we've discovered now need doing, what is the next piece we need to do and is it worth continuing.

newfie_bullet 8y ago
great read. thanks for sharing
harryf 8y ago
> You cannot estimate what you don't know Exactly! It tried to express that and a strategy for handling unknowns here - https://medium.com/@hfuecks/what-donald-rumsfeld-can-teach-us-about-software-estimates-1be22864e509 https://medium.com/@hfuecks/what-donald-rumsfeld-can-teach-u... My theory is the reason why we’re not getting any better at estimating software projects rests on a flawed assumption; because computers are binary and deterministic, we assume that the process of creating software must also be deterministic and quantifiable. Example: when Apple opened the App Store to 3rd party developers, would it be realistic to expert an accurate estimate from one of those developers, building their first app? There were so many unknowns; how does the build / publish process work? what will pass the review process? what about all these new APIs?
- softawre 8y ago
  Agile has a concept called the cone of uncertainty. The way we use this concept in practice is by doing small chunks and delivering fast, and the more chunks we have done with a project/feature/whatever the more likely our estimates get better over time because there is less work left and we are more familiar with the work now. http://www.agilenutshell.com/cone_of_uncertainty http://www.agilenutshell.com/cone_of_uncertainty
  - AstralStorm 8y ago
    Sometimes there are no "small chunks" and this is where all agile approaches fail. If a thing does not work it is not a deliverable. Bonus points if the thing is not really testable because it is tied to platform/OS. (And you'd either have to implement it in full our spend weeks implementing a test harness.)
    - jacques_chester 8y ago
      > Sometimes there are no "small chunks" and this is where all agile approaches fail. I work at Pivotal. Cloud Foundry is a successful application of agile (XP + Lean trimmings) to a large, complex distributed system.

newfie_bullet 8y ago

great read. thanks for sharing

harryf 8y ago

> You cannot estimate what you don't know Exactly! It tried to express that and a strategy for handling unknowns here - https://medium.com/@hfuecks/what-donald-rumsfeld-can-teach-us-about-software-estimates-1be22864e509 https://medium.com/@hfuecks/what-donald-rumsfeld-can-teach-u... My theory is the reason why we’re not getting any better at estimating software projects rests on a flawed assumption; because computers are binary and deterministic, we assume that the process of creating software must also be deterministic and quantifiable. Example: when Apple opened the App Store to 3rd party developers, would it be realistic to expert an accurate estimate from one of those developers, building their first app? There were so many unknowns; how does the build / publish process work? what will pass the review process? what about all these new APIs?

softawre 8y ago
Agile has a concept called the cone of uncertainty. The way we use this concept in practice is by doing small chunks and delivering fast, and the more chunks we have done with a project/feature/whatever the more likely our estimates get better over time because there is less work left and we are more familiar with the work now. http://www.agilenutshell.com/cone_of_uncertainty http://www.agilenutshell.com/cone_of_uncertainty
- AstralStorm 8y ago
  Sometimes there are no "small chunks" and this is where all agile approaches fail. If a thing does not work it is not a deliverable. Bonus points if the thing is not really testable because it is tied to platform/OS. (And you'd either have to implement it in full our spend weeks implementing a test harness.)
  - jacques_chester 8y ago
    > Sometimes there are no "small chunks" and this is where all agile approaches fail. I work at Pivotal. Cloud Foundry is a successful application of agile (XP + Lean trimmings) to a large, complex distributed system.