4 ms·

Evidence Based Scheduling - Joel on Software

36 points by luccastera 19y ago

joshwa 19y ago
Sounds a lot like FDD/Agile-- lots of estimation, and getting a good read on team velocity.
- jkush 19y ago
  ...with an emphasis on helping management be rational.
Readmore 19y ago
Joel is an excellent salesman! Based on his article I totally want that feature now, and not only did he make it sound great he also made it sound in-depth enough that I would rather pay for it than waste time trying to re-create it. Very nice.
Goladus 19y ago
I thought an evidence-based guess was called a hypothesis. Anyway, my problem with scientific analysis of my work habits has always been the observation phase. I can keep timesheets, but that turns out not to be useful data because I only keep timesheets reliably when I'm full of energy. When I'm full of energy, I'm more productive at everything.
- michaelneale 19y ago
  That would be consistent with my experience.
  - aston 19y ago
    Empiricism, yes.
    - michaelneale 19y ago
      ??
      - aston 19y ago
        You agreed about empiricism by using your own empirical evidence.
        michaelneale 19y ago
        Yeah but I don't get why you are pointing that out? Am I missing something?
        Goladus 19y ago
        You posted an evidence-based conclusion.
        michaelneale 19y ago
        I didn't think it was a conclusion, just agreement based on experience.
- qaexl 19y ago
  I have the same experience too. However, when I run though what Joel was talking about, you create a feature list with the estimate first. Keeping track of the time you spent on a feature means going down the list and putting down how much time you spent on it. Keeping track of time by just entering in a log has always been problematic for me. And not having to keep track of interruptions is even better.
dpapathanasiou 19y ago
Past results are no guarantee of future performance ;)
Tichy 19y ago
Could work well in combination with Mylin: http://www.eclipse.org/mylyn/ http://www.eclipse.org/mylyn/ (monitors how long you take for completing your programming tasks).
- michaelneale 19y ago
  No Joel didn't mention mylin. So it can't be useful at all ;)
tx 19y ago
"P.S. Evidence Based Scheduling is built into FogBugz 6.0." Ahh! Of course...
- emfle 19y ago
  Yes, he thinks evidence based scheduling is a worthwhile thing to do, so he builds the feature into his application, then blogs about it. How dare he.
mhidalgo 19y ago
This method works for larger companies with lots of data. As a startup I find it hard to see this being implemented.
- DougBTX 19y ago
  The predictions are per-developer, so it shouldn't matter how many developers you have. I think it would work for any developer who wants to improve their ability to set deadlines, it just has some ramp-up time before the predictions become useful.
nikolaj 19y ago
of all the attempts i have made at estimating.. only one works pretty much spot on. Essentially, take the gut feeling, double it, double it again, and add an increment. Example1: gut estimate is "yeah, thats a five hour task".. so, 5 -> 10 -> 20 plus.. oh.. 2 hours, so 22. Seems absurdly large, yes, but factor in all those little thingsl, testing, deploying, etc, and lo and behold, two days plus some is gone. Example2: Hmm, 2 weeks of solid (40hr week) dev time. So, 2->4->8 + 1 = 9 weeks. Woah, yeah that seems a bit large for project X.. but wait, client drags on assets, unforseen issues here and there, run into a snag for a couple days.. and boom!, almost two months have gone by. I know it feels dishonest to so drastically overestimate what you Really think it will take, but the truth is the reason there is so much distrust of programmers by business people is that we so consistently miss deadlines. I know the estimate seems huge, but it needs to be, because ultimately it is very realistic, and if you beat it (doubtfully by much), everyone will be happy. An oversized estimate finished early is better than an undersized estimate finished late. Always.
jsnx 19y ago
This approach should be sensitive to sample size, but I don't see any discussion of that. If he's tried it a lot, there should be some discussion of error on the first 10 hours, 100 hours, 1000 hours...

36 points by luccastera 19y ago

joshwa 19y ago

Sounds a lot like FDD/Agile-- lots of estimation, and getting a good read on team velocity.

jkush 19y ago
...with an emphasis on helping management be rational.

Readmore 19y ago

Joel is an excellent salesman! Based on his article I totally want that feature now, and not only did he make it sound great he also made it sound in-depth enough that I would rather pay for it than waste time trying to re-create it. Very nice.

Goladus 19y ago

I thought an evidence-based guess was called a hypothesis. Anyway, my problem with scientific analysis of my work habits has always been the observation phase. I can keep timesheets, but that turns out not to be useful data because I only keep timesheets reliably when I'm full of energy. When I'm full of energy, I'm more productive at everything.

michaelneale 19y ago
That would be consistent with my experience.
- aston 19y ago
  Empiricism, yes.
  - michaelneale 19y ago
    ??
    - aston 19y ago
      You agreed about empiricism by using your own empirical evidence.
      - michaelneale 19y ago
        Yeah but I don't get why you are pointing that out? Am I missing something?
        Goladus 19y ago
        You posted an evidence-based conclusion.
        michaelneale 19y ago
        I didn't think it was a conclusion, just agreement based on experience.
qaexl 19y ago
I have the same experience too. However, when I run though what Joel was talking about, you create a feature list with the estimate first. Keeping track of the time you spent on a feature means going down the list and putting down how much time you spent on it. Keeping track of time by just entering in a log has always been problematic for me. And not having to keep track of interruptions is even better.

dpapathanasiou 19y ago

Past results are no guarantee of future performance ;)

Tichy 19y ago

Could work well in combination with Mylin: http://www.eclipse.org/mylyn/ http://www.eclipse.org/mylyn/ (monitors how long you take for completing your programming tasks).

michaelneale 19y ago
No Joel didn't mention mylin. So it can't be useful at all ;)

tx 19y ago

"P.S. Evidence Based Scheduling is built into FogBugz 6.0." Ahh! Of course...

emfle 19y ago
Yes, he thinks evidence based scheduling is a worthwhile thing to do, so he builds the feature into his application, then blogs about it. How dare he.

mhidalgo 19y ago

This method works for larger companies with lots of data. As a startup I find it hard to see this being implemented.

DougBTX 19y ago
The predictions are per-developer, so it shouldn't matter how many developers you have. I think it would work for any developer who wants to improve their ability to set deadlines, it just has some ramp-up time before the predictions become useful.

nikolaj 19y ago

of all the attempts i have made at estimating.. only one works pretty much spot on. Essentially, take the gut feeling, double it, double it again, and add an increment. Example1: gut estimate is "yeah, thats a five hour task".. so, 5 -> 10 -> 20 plus.. oh.. 2 hours, so 22. Seems absurdly large, yes, but factor in all those little thingsl, testing, deploying, etc, and lo and behold, two days plus some is gone. Example2: Hmm, 2 weeks of solid (40hr week) dev time. So, 2->4->8 + 1 = 9 weeks. Woah, yeah that seems a bit large for project X.. but wait, client drags on assets, unforseen issues here and there, run into a snag for a couple days.. and boom!, almost two months have gone by. I know it feels dishonest to so drastically overestimate what you Really think it will take, but the truth is the reason there is so much distrust of programmers by business people is that we so consistently miss deadlines. I know the estimate seems huge, but it needs to be, because ultimately it is very realistic, and if you beat it (doubtfully by much), everyone will be happy. An oversized estimate finished early is better than an undersized estimate finished late. Always.

jsnx 19y ago

This approach should be sensitive to sample size, but I don't see any discussion of that. If he's tried it a lot, there should be some discussion of error on the first 10 hours, 100 hours, 1000 hours...