4 ms·

Recently I had the notion of making a variant of MS Project where the Gantt charts can have range estimates, conditionals, and general probabilistic features.

Recently I had the notion of making a variant of MS Project where the Gantt charts can have range estimates, conditionals, and general probabilistic features. Then simply use Monte Carlo to run a few hundred thousand iterations to determine not just the estimate range (with probability curves!), but also things such as "which step is more critical to timely delivery?" and "who can't go on holidays during critical periods, and what are those periods?" Etc... Turns out that there are about a dozen such tools already, and people do use them for estimating complex projects. Think ITER and the like. Fundamentally, it all goes back to what you said: You simply move forward every day and stop when it's "good enough". All the estimation in the world won't change the path you take. At most it'll decide if you embark on the journey, or not at all.

TeMPOraL 4y ago
> Turns out that there are about a dozen such tools already, and people do use them for estimating complex projects. Think ITER and the like. Can you link some? Some year ago, I spent many hours searching for exactly that, started a bunch of threads on social media, and in the end found nothing useful at all - except for one lead I accidentally discovered near the end: GERT, as in "Graphical Evaluation and Review Technique", or "let's take PERT and add proper directed graphs, and notions of conditionals and probabilities". https://en.wikipedia.org/wiki/Graphical_Evaluation_and_Review_Technique https://en.wikipedia.org/wiki/Graphical_Evaluation_and_Revie... Unfortunately, I stumbled on that at the very tail end of my search, and had no time to dig deeper - but I assume if the software industry knew or cared about this, I'd have seen it mentioned earlier in any of the dozens of "project management" tools and startups I've looked at.
BarryMilo 4y ago
> Fundamentally, it all goes back to what you said: You simply move forward every day and stop when it's "good enough". To me this is a basic requirement of a truly agile approach, but management always turns it into"waterfall with weekly meetings".
- fnordpiglet 4y ago
  Yeah I was developing in the thought works crowd in the SF 90s, and agile was a wonderful insight into how to best create high velocity and high quality, with high morale, software. I went into quant trading for a long time which by its nature is agile so missed out on the process adaptation of agile. The problem came when folks added story points and burn down charts - this invited the process people in the door to make things more predictable, which invited the management in to consume that desired predictability. My belief is software, for whatever reason, suffers from an uncertainty paradox. The act of measuring development impedes and slows development.
rqtwteye 4y ago
“Fundamentally, it all goes back to what you said: You simply move forward every day and stop when it's "good enough". All the estimation in the world won't change the path you take. At most it'll decide if you embark on the journey, or not at all.” I often wish management would worry more about productivity vs estimates. In my company the only thing that comes from project management is the desire for better estimates. Nobody seems to really care about improving processes and staffing.
- jiggawatts 4y ago
  > I often wish management would worry more about productivity vs estimates. A thousand times this. I just tried to explain to a manager overseeing developers that the minimum time for the "inner loop" of edit-build-debug is super important to productivity. He just didn't get it, and was fine with adding multi-minute delays to that loop on his team just to avoid speaking to another manager once.
jkaptur 4y ago
I created one of these tools when I interned at Crystal Ball (before it was acquired by Oracle. On the on hand, it really was as slick as you'd hope - like, since we used Project for the calculation engine, and Project integrates with Outlook's calendar, you can see that if Alice is the only one that can complete a task, that task can't be done while she's on vacation, etc. On the other hand, I never had a chance to see it used for real (honestly, I'm not sure it ever was), but I'm not sure it would help. The results are hugely sensitive to the distributions, and the whole point is that even the distributions are difficult to estimate - you just don't know what you don't know.

TeMPOraL 4y ago

> Turns out that there are about a dozen such tools already, and people do use them for estimating complex projects. Think ITER and the like. Can you link some? Some year ago, I spent many hours searching for exactly that, started a bunch of threads on social media, and in the end found nothing useful at all - except for one lead I accidentally discovered near the end: GERT, as in "Graphical Evaluation and Review Technique", or "let's take PERT and add proper directed graphs, and notions of conditionals and probabilities". https://en.wikipedia.org/wiki/Graphical_Evaluation_and_Review_Technique https://en.wikipedia.org/wiki/Graphical_Evaluation_and_Revie... Unfortunately, I stumbled on that at the very tail end of my search, and had no time to dig deeper - but I assume if the software industry knew or cared about this, I'd have seen it mentioned earlier in any of the dozens of "project management" tools and startups I've looked at.

BarryMilo 4y ago

> Fundamentally, it all goes back to what you said: You simply move forward every day and stop when it's "good enough". To me this is a basic requirement of a truly agile approach, but management always turns it into"waterfall with weekly meetings".

fnordpiglet 4y ago
Yeah I was developing in the thought works crowd in the SF 90s, and agile was a wonderful insight into how to best create high velocity and high quality, with high morale, software. I went into quant trading for a long time which by its nature is agile so missed out on the process adaptation of agile. The problem came when folks added story points and burn down charts - this invited the process people in the door to make things more predictable, which invited the management in to consume that desired predictability. My belief is software, for whatever reason, suffers from an uncertainty paradox. The act of measuring development impedes and slows development.

rqtwteye 4y ago

“Fundamentally, it all goes back to what you said: You simply move forward every day and stop when it's "good enough". All the estimation in the world won't change the path you take. At most it'll decide if you embark on the journey, or not at all.” I often wish management would worry more about productivity vs estimates. In my company the only thing that comes from project management is the desire for better estimates. Nobody seems to really care about improving processes and staffing.

jiggawatts 4y ago
> I often wish management would worry more about productivity vs estimates. A thousand times this. I just tried to explain to a manager overseeing developers that the minimum time for the "inner loop" of edit-build-debug is super important to productivity. He just didn't get it, and was fine with adding multi-minute delays to that loop on his team just to avoid speaking to another manager once.

jkaptur 4y ago

I created one of these tools when I interned at Crystal Ball (before it was acquired by Oracle. On the on hand, it really was as slick as you'd hope - like, since we used Project for the calculation engine, and Project integrates with Outlook's calendar, you can see that if Alice is the only one that can complete a task, that task can't be done while she's on vacation, etc. On the other hand, I never had a chance to see it used for real (honestly, I'm not sure it ever was), but I'm not sure it would help. The results are hugely sensitive to the distributions, and the whole point is that even the distributions are difficult to estimate - you just don't know what you don't know.