9 ms·

Is it going to take more than two hours? Is it going to take more than two days? Is it going to take more than two weeks? Is it going to take more than two m

by xn 8mo ago

Is it going to take more than two hours? Is it going to take more than two days? Is it going to take more than two weeks? Is it going to take more than two months? Is it going to take more than two years? If you can answer these questions, you can estimate using a confidence interval. If the estimate is too wide, break it down into smaller chunks, and re-estimate. If you can't break it down further, decide whether it's worth spending time to gather information needed to narrow the estimate or break it down. If not, scrap the project.

swat535 8mo ago
I like this approach, it's more accurate than T-shirt sizing.
dchuk 8mo ago
I prefer 1 hour/1 day/etc but yes, this is the only method that I’ve found to work. Be very clear what result you’re trying to produce, spec out the idea in detail, break down the spec into logical steps, use orders of magnitude to break down each step. There’s your estimate. If you can’t break it down enough to get into the 1 day/1 week range per step, you don’t actually have a plan and can’t produce a realistic estimate
scott_w 8mo ago
There’s also something more concrete about asking “Can you get it done by end of tomorrow? What does that require?” I prefer it over estimating which feels more like asking the length of a piece of string.
- alfiedotwtf 8mo ago
  The problem I have is, conceptually a task always looks easy, but then as your coding, you hit several problems that are not simple to overcome - in fact, lot of times these issues turn into almost insolvable problems that blow out any time estimates ;(
  - napaparts 8mo ago
    It really depends. Anyone doing meaningful work will have hard time giving estimates. But churning up the next CRUD application with now special requirements can have no unknown variables. The question of course remains, why would anyone want to waste their time reinventing a spreadsheet.
    - arter45 8mo ago
      >why would anyone want to waste their time reinventing a spreadsheet I hope this is tongue in cheek, right? If not, here are some reasons: 1) spreadsheets embed "functions" via macros and macros are often flagged as malicious. Just combining native functions can get pretty complex. 2) in a spreadsheet, everybody sees the input, which is not always ideal 3) data types are controlled by users for the entire column or sheet, which can mess up formulas I could probably think of additional reasons.
      - napaparts 8mo ago
        You are correct, comparing making the next CRUD application to reinventing the spreadsheet was supposed to be a slightly humorous way to describe the repetitive and not too challenging part of writing business applications. There also are people who use software to guide space rockets, cars, optimise calculation algorithms and more. My guess is people with background mostly in CRUD don't get how everybody else messes up estimating so badly and people in the innovative task group find it hard to believe sane people would waste their time giving any estimates other than for technically irrelevant business reasons.
  - scott_w 8mo ago
    That’s why time limiting rather than estimating works for me. It forces me to contend with the question: “can I get this done today?” That’s usually an easier question to answer because it’s to tightly time bound. I’m not always correct but I’ll know tomorrow if I wasn’t, rather than next month! When I’m asked on longer time frames, I’m much less confident but it’s still more concrete than the other way around.
  - 8mo ago
n4r9 8mo ago
What if the project involves trying one approach for a week, then assessing whether that approach still looks viable vs moving onto a different approach? This happens a lot with challenging projects, you basically just keep trying different things until one works.
- xn 8mo ago
  Then you know that it's going to take at least, say two weeks, one week for the first implementation and a week to finish it if it works. On the high end, could it take more than 2 years? 1 year? 6 months? Stop when you are 80% confident that it won't take longer than some period. So your estimate might be between two weeks and six months. Is that an acceptable estimate for the "buyer"? If not, is it worth expending effort to narrow the estimate?
  - n4r9 8mo ago
    Yes, this is basically what happens. Except sometimes there's no realistic way to narrow the estimate. In research-focused teams you don't "scrap" a project that you can't break down. Instead you need to have a way to manage wide estimate windows.

by xn 8mo ago

swat535 8mo ago

I like this approach, it's more accurate than T-shirt sizing.

dchuk 8mo ago

I prefer 1 hour/1 day/etc but yes, this is the only method that I’ve found to work. Be very clear what result you’re trying to produce, spec out the idea in detail, break down the spec into logical steps, use orders of magnitude to break down each step. There’s your estimate. If you can’t break it down enough to get into the 1 day/1 week range per step, you don’t actually have a plan and can’t produce a realistic estimate

scott_w 8mo ago

There’s also something more concrete about asking “Can you get it done by end of tomorrow? What does that require?” I prefer it over estimating which feels more like asking the length of a piece of string.

alfiedotwtf 8mo ago
The problem I have is, conceptually a task always looks easy, but then as your coding, you hit several problems that are not simple to overcome - in fact, lot of times these issues turn into almost insolvable problems that blow out any time estimates ;(
- napaparts 8mo ago
  It really depends. Anyone doing meaningful work will have hard time giving estimates. But churning up the next CRUD application with now special requirements can have no unknown variables. The question of course remains, why would anyone want to waste their time reinventing a spreadsheet.
  - arter45 8mo ago
    >why would anyone want to waste their time reinventing a spreadsheet I hope this is tongue in cheek, right? If not, here are some reasons: 1) spreadsheets embed "functions" via macros and macros are often flagged as malicious. Just combining native functions can get pretty complex. 2) in a spreadsheet, everybody sees the input, which is not always ideal 3) data types are controlled by users for the entire column or sheet, which can mess up formulas I could probably think of additional reasons.
    - napaparts 8mo ago
      You are correct, comparing making the next CRUD application to reinventing the spreadsheet was supposed to be a slightly humorous way to describe the repetitive and not too challenging part of writing business applications. There also are people who use software to guide space rockets, cars, optimise calculation algorithms and more. My guess is people with background mostly in CRUD don't get how everybody else messes up estimating so badly and people in the innovative task group find it hard to believe sane people would waste their time giving any estimates other than for technically irrelevant business reasons.
- scott_w 8mo ago
  That’s why time limiting rather than estimating works for me. It forces me to contend with the question: “can I get this done today?” That’s usually an easier question to answer because it’s to tightly time bound. I’m not always correct but I’ll know tomorrow if I wasn’t, rather than next month! When I’m asked on longer time frames, I’m much less confident but it’s still more concrete than the other way around.
- 8mo ago

n4r9 8mo ago

What if the project involves trying one approach for a week, then assessing whether that approach still looks viable vs moving onto a different approach? This happens a lot with challenging projects, you basically just keep trying different things until one works.

xn 8mo ago
Then you know that it's going to take at least, say two weeks, one week for the first implementation and a week to finish it if it works. On the high end, could it take more than 2 years? 1 year? 6 months? Stop when you are 80% confident that it won't take longer than some period. So your estimate might be between two weeks and six months. Is that an acceptable estimate for the "buyer"? If not, is it worth expending effort to narrow the estimate?
- n4r9 8mo ago
  Yes, this is basically what happens. Except sometimes there's no realistic way to narrow the estimate. In research-focused teams you don't "scrap" a project that you can't break down. Instead you need to have a way to manage wide estimate windows.