Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hacks for Engineering Estimates

shubhro.com

Post reply on HN
Print view View original

31–40 of 41 posts

Re: Hacks for Engineering Estimates

#31

Post by redcalx »

abetlen wrote: post #11

My go-to heuristic is three point estimation, basically a weighted average of the best, worst, and average case [0]. (Best + Worst + 4 * Average) / 6 One nice property is that it imposes a distribution that adjusts for longer tailed risks. https://en.wikipedia.org/wiki/Three-point_estimation

So one question here is: Why reduce the distribution (with long tail or whatever) to a single estimate number? If the distribution represents the range of possible outcomes well, then the single number throws away most of the information in the distribution.

Re: Hacks for Engineering Estimates

#32

Post by steveBK123 »

throwaway4good wrote: post #4

I think the biggest thing holding engineering estimates back is that the people asking for them are actually not interested in accurate estimates; instead they are looking for inputs to be used in various games of corporate politics.

Correct. The good answers assume the askers actually want ACCURATE estimates. In many many cases this is not true at all.

I've worked for guys that shop around and give the work to the lowest estimator, even when they have a track record of low-balling and then running 5x over their estimates.

In other scenarios, to your point, optimistically low estimates are used as a political tool by product/management to wrestle some task/responsibility from some other team in the org.

Inevitably what I see again and again is everyone takes (and fights devs for) low-ball estimates, which assume the happy path of "nothing can go wrong". They are then happy to hear & communicate to clients the various excuses when each "downside surprise" is discovered through the development process. Of course the estimate high-baller has built in time for these as theres rarely positive surprises that make tasks faster, and few tasks are surprise free.

Re: Hacks for Engineering Estimates

#33

Post by steveBK123 »

cybadger wrote: post #13
dncornholio wrote: post #8

When I make an estimate, I just double what I think it is and this is usual pretty accurate. I keep underestimating, sometimes doubling down I wonder myself, will it really take this long? 99% of the time, in the end, the answer was yes. So this is my goto method. People still think I finish stuff quick, even if I think myself it's too long.

My favorite estimation hack / joke is similar: take your best estimate, double it, and move up to the next higher time units. So "oh, an hour or so" becomes 2 days. A week turns into two months. I don't usually express those estimates, but it gives a good check on an initial, usually optimistic guess.

This sounds about right. I worked with a guy who never gave an estimate more than "an hour" or "I can bang this out in a weekend". Of course quite often he'd end up working on the feature for 3 months...

Re: Hacks for Engineering Estimates

#34

Post by steveBK123 »

throwaway98797 wrote: post #19

some things can be estimated, others not so much often folks don’t know if what is being estimated is actually knowable. building something new pre product market fit is a crapshoot until it’s not.

yes this is one of the agile issues

we try to tightly manage estimates & timelines on small iterative tasks, breaking up any larger work items into smaller and smaller stories, in beautiful hierarchies of tickets..

the only innovative work happens out of sprint / nights & weekends as unapproved stuff that would have been nickel&dimed into 27 stories across 10 sprints if it went through the agile process

in a Greenfield project these sorts of estimates driven iterative work methods are innovation killers

Re: Hacks for Engineering Estimates

#35

Post by fishtoaster »

I feel like "Note the Precision" is one that I most see missed.

Partially, this is on engineers. They'll say "That'll take 36 days" and not realize that they're implying a higher level of specificity than they intend.

Partially, this is on consumers of estimates (managers, etc). They'll hear "It'll be about 36 days, but that's just a super rough estimate, we haven't planned it out yet, it could be way more..." but they stopped listening and wrote down "estimate: 36 days."

My current eng team has fixated on two distinct levels of eng estimates. The first is super high level: "minutes to hours", "hours to days," "days to weeks", "weeks to months," or "months to quarters." The second is a number of hours. We give out the high-level estimates freely - they're super helpful for project planning. We give out the second number only when we have a pretty solid plan with estimated tickets.

It's worked pretty well because engineers can always be clear on which estimation type is called for. It's also helpful because non-engineers can get used to hearing the high-level estimates pretty quickly and know to treat them as super vague.

* We actually deliver all hour estimates as 30/60/90 estimates: "we're 30% sure it'll be done in 36 hours, 60% sure it'll be done in 50 hours, and 90% sure it'll be done in 80 hours". There's still a tendency of people to just use the 60% estimate as "The Estimate," but it's better than nothing.

Re: Hacks for Engineering Estimates

#36

Post by redcalx »

williamkuszmaul wrote: post #27

One estimation trick that I've found effective is the following: (1) determine the smallest number that your sure is larger than the true answer. (2) determine the largest number that you are sure is smaller than the true answer. (3) take the geometric average of the two. (i.e., sqrt(a * b)) The reason this does well, is that oftentimes, (1) overestimates the true answer by roughly the same multiplicative factor as (…

So basically, if there's a distribution of possible outcomes (with estimated duration plotted on the x-axis, and probability on the y-axis), then we put bounds on either side of the distribution and take a 'central' point on the x-axis between them. But instead of a simple average, we can use a log scale on the x-axis, so that we represent estimates of different magnitudes well. Now the simple half way point on the x-axis is on a log scale, and (I think) equivalent to the approach you described.

Re: Hacks for Engineering Estimates

#37

Post by netghost »

redcalx wrote: post #31
abetlen wrote: post #11

My go-to heuristic is three point estimation, basically a weighted average of the best, worst, and average case [0]. (Best + Worst + 4 * Average) / 6 One nice property is that it imposes a distribution that adjusts for longer tailed risks. https://en.wikipedia.org/wiki/Three-point_estimation

So one question here is: Why reduce the distribution (with long tail or whatever) to a single estimate number? If the distribution represents the range of possible outcomes well, then the single number throws away most of the information in the distribution.

I strongly agree, giving people the distribution conveys a lot of information especially if everyone is clear on what the parameters of that distribution mean (ie: what's the low estimate mean?).

At the same time, there are occasions where it can be useful to collapse a distribution for some types of reports, or for quickly looking across estimates.

Re: Hacks for Engineering Estimates

#38

Post by marcosdumay »

Always keep in mind that estimate errors follow a long-tailed distribution. That means that if you estimate enough things, your total error will be defined by one or two tasks, it doesn't matter how you did for 95% of them.

Thus, if your goal is to lie to management stating that "we met 98% of our estimations last year" implying that because of this, there is not problem, then yes, go work on improving your estimates.

If your goal is to get things done so you can get some real progress, go set realistic targets on time or ROI and learn to throw away tasks that failed it.

And if your goal is to never get an estimation wrong, because they are commitments that you can never get free after you made them, go practice your interview skills and move to a better environment.

Re: Hacks for Engineering Estimates

#39

Post by zo1 »

NAHWheatCracker wrote: post #23
throwaway4good wrote: post #4

I think the biggest thing holding engineering estimates back is that the people asking for them are actually not interested in accurate estimates; instead they are looking for inputs to be used in various games of corporate politics.

This is precisely the issue from my perspective as well. Most project managers I've worked with either have a desired estimate already in mind or they don't care about any of the extenuating circumstances. On one hand, the desired estimate is often based on the knowledge that projects estimated to take more than a quarter aren't going to get a green light. On the other hand, it's ridiculous how many projects blow thr…

And as someone asking developers for those estimates, I often see all sorts of equivalents that we complain managers have in the form of politics.

Devs over-engineer, add way too much padding for refactoring and cleaning out tech-debt than is necessary, devs engineer solutions with resume padding, devs like playing with cool tech or trying new tech instead of just using "the boring old thing", they over-engineer (saying this one twice), they get it wrong, devs over-compensate because they got burned previously, they over-compensate because they got negotiated down and then it went bad, they want to impress their peers or whoever they report to, they get bullied by end users that somehow get access to them, etc etc. Yes a lot of those are avoidable, but we don't live in an ideal world.

Re: Hacks for Engineering Estimates

#40

Post by infogulch »

redcalx wrote: post #36
williamkuszmaul wrote: post #27

One estimation trick that I've found effective is the following: (1) determine the smallest number that your sure is larger than the true answer. (2) determine the largest number that you are sure is smaller than the true answer. (3) take the geometric average of the two. (i.e., sqrt(a * b)) The reason this does well, is that oftentimes, (1) overestimates the true answer by roughly the same multiplicative factor as (…

So basically, if there's a distribution of possible outcomes (with estimated duration plotted on the x-axis, and probability on the y-axis), then we put bounds on either side of the distribution and take a 'central' point on the x-axis between them. But instead of a simple average, we can use a log scale on the x-axis, so that we represent estimates of different magnitudes well. Now the simple half way point on the x…

The geometric mean being equivalent to the arithmetic mean of values transformed under a log scale is an interesting perspective that I haven't considered, but appears to be well known. https://en.wikipedia.org/wiki/Geometric_mean
Post reply on HN