[lacey]

Do you have specific resources you would recommend for learning to produce better estimates?

I'm also curious what kind of work you do that you find estimating effort to be reliable, and what kind of tracking you do to keep yourself honest (e.g. I often see people say something will take two weeks and the only reason it happens in two weeks is they end up working day and night for the last 5-7 days when they realize that's what it's going to take to make it happen).

[techbio]

One thing: More, smaller estimates, have the property of being wrong by a lesser amount, and they are likely to cancel each other out. Estimates in hours instead of weeks are far less likely to block your work in progress for as long. Teams also get more feedback and opportunities to practice estimating, and more granular work is rewarding more often.

[lovich]

That idea works out, and is the basis of agile vs waterfall, but there's a point where you shrink the timelines so much that you'll end up spending more time estimating work than you soend doing it

[techbio]

Quick estimates that are good magnitude approximations but often somewhat wrong have a way of getting better, whereas estimates whose main purpose is to be within some delta of the actual time are working from the wrong value metric. A reasonably accurate aggregate of estimates doesn't require them all to have been perfected first. Teams that are obsessed with this will be slower to a build.

[yebyen]

This is a theme in parallelization that I remember from my more senior and upper level Computer Science seminars at RIT. I remember vaguely this coming up in one talk in particular about Manticore and Concurrent ML.

The work splitting algorithm needs to monitor the overall depth of the queue, as well as the number of workers that are online and their propensity for finishing jobs.

It doesn't help to divide a task into 100 chunks instead of only 20, if there are only 8 workers, especially when each split has a marginal cost that will add up again and factor in to overall cost at the point of final integration.

But with a pool of 1000 workers, dividing the work into only 20 or even 100 chunks might still be leaving significant amounts of power on the table undesirably.

You could try to optimize for both, strike a balance between achieving an earliest possible completion time, and minimizing waste. But there are going to be maxima and minima of either on a continuum, may not be practical to find the sweet spot.

One place where this analogy breaks down, is that computers do not care one iota if their work is redundant, or if their work must be thrown away. Human developers care, even if it might save the employers some bit of money or reduce a risk. Humans usually will not produce identical outputs either, when they are assigned redundant workloads. Most humans would probably prefer not to work on a project that is redundant at all. Computers don't care, ML doesn't care. But it would be soul crushing for devs to have to work in an environment like that. I'm sure it happens more than I would have imagined.

[hectormalot]

I find this (short term estimates) only work when you are self sufficient as a person or team. E.g. as soon as something like: “I need to get access to the managed AD service” or “the service desk needs to be trained to handle requests on this new feature” come in, I find planning to be very difficult. That AD access technically takes 10 minutes, but might take 2 weeks of approval meetings and emails.

Especially prevalent during the initial start of a new project