Comment by embwbam | Hacker News Reader

Comment by embwbam | Hacker News Reader

Parent Full thread

In my experience, one can accurately predict development time by correctly working around the planning fallacy.

The planning fallacy is something like "Humans are hopelessly optimistic. Even if you think you're planning for the worst case, unexpected things will happen, and your estimate is more like the best case scenario. This is true even if you try to compensate for the planning fallacy by being more pessimistic".

So you can't fix it by padding more weeks, trying to think of all the things that might happen, etc.

The only way to compensate for this is detailed in Kahneman's "Thinking Fast and Slow" (Must-read for many reasons). That is to start with prior evidence. Rather than making your estimate, start with "How long did it ACTUALLY take the last time someone did something like this?" and only then modifying the estimate for circumstances.

There is a huge gap between these two methods:

1. "How long does it take an average team to create a SAS product? Maybe a year?" Then modify for "but our team is extra smart, so maybe I'll shorten that to 10 months"

vs

2. "How long will this take? It's not a complicated product, and our team is smart: maybe 4 weeks for feature X, 6 for feature Y, 2 to deploy. I'll even throw in an extra 4 weeks of padding for unknowns, so 16 weeks".

As far as I can tell there are two major problems with this.

The first is that you can predict that there will be unforeseen problems, but not how many of them nor how long each will take to resolve. The result is high variance. Then if the average such project takes 16 months, and you predict each such project will take 16 months, then some take 7 months and some take 17 months and some take 25 months and people get mad at you for underestimating some of them. But if you predict at the upper end of the range then people will get mad at you for giving 25 month estimates for projects that only take 16 months on average.

The second is that people know what the estimate is and work expands to fill all available time. When you know you have 16 months, you set a pace that will have the project finished in 16 months. Then in month 14 you encounter some unexpected problem that takes six months to resolve. If you'd found it in month 2 you'd have been fine, because you'd have cut some less critical features and spent the time on that, but now that's in the past and your project is five months late.

The third major problem:

Project Manager/Scheduler/Sales/Customer doing one/any/all of: not believing the input of the SME (you) when they ask for input developing the schedule, overpromising, expecting the world, or so many other problems.

Too many times in my own field (heavy construction) the scheduler has asked me how long it will take to do a given task, and it is actually reasonably quantifiable to say "It will take my crew X days to move Y volume of material at Z/shift" only to be told "Well our proposal only allocated X-5 days and budgeted a Crew of <your chosen size - 4> for that task. Figure it out."

> How long did it ACTUALLY take

Haha, I came to that same conclusion decades ago - I don't know if it would actually produce meaningful estimates or not, though, because every time I try to estimate that way, somebody more "important" than me comes along and throws out that estimate for one that fits the timeline he already had in mind.

Lol, you’re not wrong. It’s pretty clear organizations prefer the illusion of getting something quickly to accurate information

And then the CTO complains that no one ever tells him the truth on how long a project will take.

This is the only thing that ever works for me, but a) you have to be doing repeated projects or high overlap, and b) it's hard to defend when a PM challenges. My response is usually "<shrug> this is how long this kind of thing has taken in the past". I do a lot of the same projects at different customers, so my gut feel is usually pretty close (and I have to give a ballpark quote, so there's some penalty to being over or under). But if it's something completely new, breaking it down in to detail tasks almost never results in a good estimate.

> That is to start with prior evidence. Rather than making your estimate, start with "How long did it ACTUALLY take the last time someone did something like this?" and only then modifying the estimate for circumstances.

This requires to have prior evidence within your team to start with as not all teams have the same velocity.

Reply on news.ycombinator.com