3 ms·

You are absolutely right. It's impossible to estimate how long it will take to complete something you have never done before in your life. Unless the new code b

You are absolutely right. It's impossible to estimate how long it will take to complete something you have never done before in your life. Unless the new code being written is absolutely trivial, estimates are going to be guesses, at best. The only half-decent solution I found so far is iterative development. Take a feature and break it down i to big rocks. Further break down the big rocks into little chunks - each that you estimate would take you less than a day to complete. Only after completing your first "big rock" in this way can you use your new data to gauge your velocity and give an estimate for completing the rest of the work that's worth the paper it's written on.

jacques_chester 13y ago
> Take a feature and break it down i to big rocks. Further break down the big rocks into little chunks - each that you estimate would take you less than a day to complete. Experimental psychologists have found that decomposing tasks increases estimate accuracy, regardless of how or why the task is decomposed. It's called the "unpacking effect". http://www.sciencedirect.com/science/article/pii/S002210310300177X http://www.sciencedirect.com/science/article/pii/S0022103103...
- webhat 13y ago
  Unpacking works great when it's clear what the tasks are going to be. In my experience the bulk of the work does not go into the project or tool itself, i.e. completing the tasks, but rather into resolving issues. I usually estimate that writing the code is anywhere from 10-20% of completing the project. Some research shows that 1 kloc of code contains between 15 and 50 defects, and that code reviewing will pick up only 70-90%. This still leaves a lot of bugs. I sometime ago wrote up some meta research on estimating code reviewing: http://specialbrands.net/2011/10/24/code-review-in-scrum-xp-agile-mathematics/ http://specialbrands.net/2011/10/24/code-review-in-scrum-xp-...
  - jacques_chester 13y ago
    > I usually estimate that writing the code is anywhere from 10-20% of completing the project. McConnell's book has a really excellent table of items that are left out of estimates. Nuts-and-bolts things like "API documentation", "deployment scripts", "status emails" and so on. > This still leaves a lot of bugs. Right. The classical software engineering theory is to build multiple quality gates and to study them for defects yielded. I recall that inspection stomps everything else; automatic testing came second. The problem of time-to-fix is subtly different from time-to-release, though. Software with known defects is regularly in use.
kabdib 13y ago
Decomposing as far as you can is a good practice ... you'll still be way off, because you think you know all the problems that you're going to need to solve. So about halfway through the project your list is going to be longer and management is going to be freaking out. The elephant in the room: Debugging. I don't know how many times I've been asked, "When are you going to find that bug?" Sometimes they are very easy. Sometimes they are very hard. For the really hard bugs, you need to be clever, scientific, determined, methodical and LUCKY. I don't know how to know when I'm going to run into some luck.
- jacques_chester 13y ago
  > you'll still be way off, because you think you know all the problems that you're going to need to solve Absolutely; but I think it's reasonable to assume that a more accurate estimate is a more valuable estimate. You can also track estimate error over time and use that to adjust future estimates. > The elephant in the room: Debugging. I don't know how many times I've been asked, "When are you going to find that bug?" The problem is that in any sample of n=1, variability is huge. It's like saying "I am going to pick one person out of the global population. How tall is he or she?" Well of course I can't know that. The sample is too small. But if instead I am told "we are going to pick ten thousand people at random from the global population; how tall are they in total?" then I can use previously-gathered statistics to give a range of estimates that will probably be accurate.

jacques_chester 13y ago

> Take a feature and break it down i to big rocks. Further break down the big rocks into little chunks - each that you estimate would take you less than a day to complete. Experimental psychologists have found that decomposing tasks increases estimate accuracy, regardless of how or why the task is decomposed. It's called the "unpacking effect". http://www.sciencedirect.com/science/article/pii/S002210310300177X http://www.sciencedirect.com/science/article/pii/S0022103103...

webhat 13y ago
Unpacking works great when it's clear what the tasks are going to be. In my experience the bulk of the work does not go into the project or tool itself, i.e. completing the tasks, but rather into resolving issues. I usually estimate that writing the code is anywhere from 10-20% of completing the project. Some research shows that 1 kloc of code contains between 15 and 50 defects, and that code reviewing will pick up only 70-90%. This still leaves a lot of bugs. I sometime ago wrote up some meta research on estimating code reviewing: http://specialbrands.net/2011/10/24/code-review-in-scrum-xp-agile-mathematics/ http://specialbrands.net/2011/10/24/code-review-in-scrum-xp-...
- jacques_chester 13y ago
  > I usually estimate that writing the code is anywhere from 10-20% of completing the project. McConnell's book has a really excellent table of items that are left out of estimates. Nuts-and-bolts things like "API documentation", "deployment scripts", "status emails" and so on. > This still leaves a lot of bugs. Right. The classical software engineering theory is to build multiple quality gates and to study them for defects yielded. I recall that inspection stomps everything else; automatic testing came second. The problem of time-to-fix is subtly different from time-to-release, though. Software with known defects is regularly in use.

kabdib 13y ago

Decomposing as far as you can is a good practice ... you'll still be way off, because you think you know all the problems that you're going to need to solve. So about halfway through the project your list is going to be longer and management is going to be freaking out. The elephant in the room: Debugging. I don't know how many times I've been asked, "When are you going to find that bug?" Sometimes they are very easy. Sometimes they are very hard. For the really hard bugs, you need to be clever, scientific, determined, methodical and LUCKY. I don't know how to know when I'm going to run into some luck.

jacques_chester 13y ago
> you'll still be way off, because you think you know all the problems that you're going to need to solve Absolutely; but I think it's reasonable to assume that a more accurate estimate is a more valuable estimate. You can also track estimate error over time and use that to adjust future estimates. > The elephant in the room: Debugging. I don't know how many times I've been asked, "When are you going to find that bug?" The problem is that in any sample of n=1, variability is huge. It's like saying "I am going to pick one person out of the global population. How tall is he or she?" Well of course I can't know that. The sample is too small. But if instead I am told "we are going to pick ten thousand people at random from the global population; how tall are they in total?" then I can use previously-gathered statistics to give a range of estimates that will probably be accurate.