Evidence Based Scheduling - Joel on Software | Hacker News Reader

Evidence Based Scheduling - Joel on Software

joelonsoftware.com

36 pointsluccastera21 comments

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.

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.

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.

That would be consistent with my experience.

Empiricism, yes.

You agreed about empiricism by using your own empirical evidence.

Yeah but I don't get why you are pointing that out? Am I missing something?

You posted an evidence-based conclusion.

I didn't think it was a conclusion, just agreement based on experience.

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.

"P.S. Evidence Based Scheduling is built into FogBugz 6.0."

Ahh! Of course...

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.

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

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.

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

...with an emphasis on helping management be rational.

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...

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

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

Past results are no guarantee of future performance

;)

Reply on news.ycombinator.com