[HN Gopher] Back of the envelope estimation hacks
___________________________________________________________________
Back of the envelope estimation hacks
Author : bkudria
Score : 138 points
Date : 2020-05-22 23:46 UTC (23 hours ago)
(HTM) web link (robertovitillo.com)
(TXT) w3m dump (robertovitillo.com)
| hoorayimhelping wrote:
| A post with some examples:
| http://highscalability.com/blog/2011/1/26/google-pro-tip-use...
| DavidPeiffer wrote:
| I've found people hate giving numbers to things when estimating
| how a system would work, or what it would need. Ballparking can
| really help though.
|
| I've found success asking questions such as "Roughly how much
| will updating my abstract cost? I won't hold you to the number,
| but are we talking closer to $200 or $800?". I make sure the
| numbers are quite far apart, and use it to figure high/low ends
| of required performance, deciding if something that's not
| currently the bottleneck will become a bottleneck, etc.
|
| Also, converting between hourly and salaried, you can roughly use
| 40 hrs/week * 50 weeks/year = 2,000 hours/year.
| pottertheotter wrote:
| I think a lot of people hate giving an estimate because they
| have learned from experience that, even if someone tells them
| they won't hold them to the number, it still happens. You might
| be the exception, but it seems to happen quite regularly.
| ddrt wrote:
| Here's my experience with that:
|
| April estimates 5 hours of work but spends 12 on it. She
| justifies her overage by communicating with the PM and
| letting them know ahead of time the task is worse off than
| they thought. But to do it right she will need to go over, by
| roughly 5 more hours. Song the way she is taking notes of
| what she's doing and then screenshots and justifications at
| the end to explain the work.
|
| Bob estimates 5 hours and takes 12. He doesn't communicate,
| the work isn't finished to spec or even partially to spec, he
| can't justify his time and argues that roadblocks kept him
| from finishing.
|
| The latter is the person I regularly deal with and I only
| know one "April".
| tdeck wrote:
| You missed one:
|
| Kevin estimates 5 hours, his manager stares at him and says
| "I don't think it's really 5 hours, we can do it in 3" and
| forces Kevin to revise his "estimate". He finishes in 10
| hours, clearly justifies the overrun, but gets a negative
| performance review.
| helldritch wrote:
| I've had discussions like this in the past, where people
| ask me "can we do it in 3 days instead of 5?" And I've
| found the easiest way to sell it to them is to ask which
| 40% of the feature set they would like me to remove from
| the deliverable?
| letientai299 wrote:
| Off topic, but I can't stop thinking about "Your lie in
| April" reading your comment.
| dvtrn wrote:
| My old man spent 30 years working as a mechanical engineer
| for General Electric in their gas turbine division and used
| to bring home these sorts of tales similar this with people
| who reported to him, which subsequently informed him on how
| he needed to communicate to the manager _he_ reported to on
| when to expect deliverables.
|
| Most memorable from this was watching his reaction while he
| and I were watching an episode of Star Trek the Next
| Generation where _his exact problem was manifested into
| reality by his favorite character_ :
| https://youtu.be/8xRqXYsksFg
|
| Nonetheless, I may or may not have employed my dad's and
| Scotty's method now that I have a team reporting up to me,
| each with their own strengths and weaknesses in delivery.
| Grooming them has been a genuine pleasure, though.
| qznc wrote:
| For work days per year, I usually use 200. It is 5 * 52 = 260.
| Now subtract vacation days in Germany: -30. Minus some
| holidays. Minus potential illness.
|
| In the US maybe 250 is closer and if you can multiply it by 4
| in further calculations somehow it becomes a power of ten.
| irrational wrote:
| American here. I would use 204: 250 - 10 holidays - 10 days
| of summer hours (something my company does in the summer) -
| 26 vacation days. My vacation days can actually rollover from
| year to year (up to a maximum of 60 days), so I could take
| off more vacations days. But, at a minimum I will get 26 days
| of vacation (on top of the 20 days of holidays and summer
| days) per year.
| Aachen wrote:
| I wonder what that number is anywhere else in the world. Most
| countries have a legal minimum paid time off higher than that
| (the USA is the exception when compared to the vast majority of
| countries, rich or poor), but most companies give a bit more
| than the minimum in our field, so what I'm wondering is whether
| the difference is large enough that rounding it up doesn't make
| sense.
|
| Personally I've got 6 paid weeks off every year (their default,
| I didn't negotiate that number) plus public holidays (iirc that
| adds up to another two weeks but maybe it's just one) with both
| my past and previous employer which were in different western
| European countries, but I don't know if that's average.
| billme wrote:
| >> " Also, converting between hourly and salaried, you can
| roughly use 40 hrs/week * 50 weeks/year = 2,000 hours/year."
|
| Even better, take just take an hourly rate, 2x it, add three
| zeros = annual salary; literally takes seconds to do once you
| know 2000 hours per year is the assumed hours worked per year.
| DavidPeiffer wrote:
| Yes, this is how I do it in my head. I should have mentioned
| that given the context of the post!
| dalore wrote:
| 50 weeks a year is very US focused. Other countries usually
| have 4 weeks off a year or more.
| saagarjha wrote:
| In this case, it's not a huge difference.
| dmurray wrote:
| And lots of workers, even hourly ones, get paid for 52
| weeks despite taking some of those off.
| saeranv wrote:
| Here's one that I learned from HN years ago
| (https://news.ycombinator.com/item?id=18463449)
|
| Rule of three: If you want to compare two things (i.e if code A
| is faster then code B), then measure each three times. If all
| three As are faster then the Bs, then there is a ~95% probability
| that is true.
|
| Derivation: We are trying to find the probability of selecting
| three As, from the set (ABABAB). We don't care about the order of
| the As, so this is a combinations without repetition problem:
|
| 6 choose 3 = n! / ((n-r)! r!)) = 6! / (3! 3!) = 120 / 6 = 20
|
| There is only one state where all three As are chosen, so the
| probability of getting it by random chance (our null hypothesis)
| is:
|
| 1 / 20 = 5%.
|
| Hence 95% confidence.
| kevinwang wrote:
| Uh oh... I think you're interpreting the probability
| incorrectly. Shouldn't this be "if we assume that a and b take
| the same amount of time, then there's a 5% chance that we would
| see this result?".
|
| Can't actually speak to the probability that a is faster than b
| without some kind of assumed prior distribution for a and b
| dmurray wrote:
| This is neat but I think your derivation needs another step: a
| Bayesian prior that before this experiment, you thought the
| probability of A beating B was 50%.
| yongjik wrote:
| Order-of-magnitude is extremely important. Frequently I find
| myself asking "So how much money is it going to save us? $100/mo,
| $1k/mo, or $10k/mo?" It's basically a nicer (and more concrete)
| way to ask "Are we sure that this project is worth the money the
| company's paying us to do it?"
|
| (Unfortunately I don't always get a satisfying answer, but that's
| life...)
| [deleted]
| heipei wrote:
| Less sophisticated, but recently I realized that just plain
| remembering certain numbers like "average hours per month" (~730)
| or "seconds per day" (86400) is really helpful to make very quick
| estimates. A customer wants a quota of 100k queries a day? That
| averages out to a little more than one query per second assuming
| equal distribution.
| kolanos wrote:
| Edit: I stand corrected.
|
| 365.25 / 12 * 24 = 730.5
|
| Technically it is 731 if you round up.
| g_sch wrote:
| I did this exact calculation and it comes out to 730, exactly
| like GP said.
| PureParadigm wrote:
| No, that evaluates to 730. It's the same as 365*2=730.
| pdonis wrote:
| The number of days per year is not exactly 365.
| pdonis wrote:
| Since you're getting downvotes and several others have posted
| disagreeing, I'm posting to agree with 730.5. I also get
| 365.25 * 2 = 730.5. I have no idea why other people are
| saying this somehow comes out to exactly 730.
|
| _> Technically it is 731 if you round up._
|
| Actually, since 365.25 is a bit high (if it were exact we
| would all still be on the Julian calendar), I would round
| down to 730 since the multiplication gives a little less than
| 730.5. But that's still not the same as saying the
| multiplication gives exactly 730, as others are saying.
| saagarjha wrote:
| I find it hilarious that so many people are so worked up on
| the rounding on the third significant figure of a number in
| the comments section of an article about "back of the
| envelope estimation hacks".
| mitjam wrote:
| 365 * 2 = 730 :)
| pdonis wrote:
| There aren't exactly 365 days in a year.
| _1100 wrote:
| We understand nothing "exactly" in this universe, but
| this is a thread about estimation hacks so maybe cool it
| on the fun fact witch hunt.? Idk just a thought.
| [deleted]
| qznc wrote:
| Rule of five: Take five samples. You can be 93% confident the
| median is between your five samples. Works for any distribution
| (not just normal).
| chrisseaton wrote:
| > Works for any distribution (not just normal).
|
| How can this possibly be true?
|
| If I take five samples of the speed of my car, and I always
| take them while the car is just setting off, it's never going
| to be anywhere near the median speed over a twelve hour drive.
|
| I feel like there must be a huge list of extra constraints and
| caveats you aren't mentioning.
|
| (I'm really bad at stats - genuinely asking.)
| qznc wrote:
| From Douglas W. Hubbard, How to Measure Anything (3rd ed.)
| via https://lobste.rs/s/kk89vp/back_envelope_estimation_hacks
| #c_...
|
| > There is a 93.75% chance that the median of a population is
| between the smallest and largest values in any random sample
| of five from that population.
|
| > It might seem impossible to be 93.75% certain about
| anything based on a random sample of just five, but it works.
| To understand why this method works, it is important to note
| that the Rule of Five estimates only the median of a
| population. Remember, the median is the point where half the
| population is above it and half is below it. If we randomly
| picked five values that were all above the median or all
| below it, then the median would be outside our range. But
| what is the chance of that, really?
|
| > The chance of randomly picking a value above the median is,
| by definition, 50%--the same as a coin flip resulting in
| "heads." The chance of randomly selecting five values that
| happen to be all above the median is like flipping a coin and
| getting heads five times in a row. The chance of getting
| heads five times in a row in a random coin flip is 1 in 32,
| or 3.125%; the same is true with getting five tails in a row.
| The chance of not getting all heads or all tails is then 100%
| - 3.125% x 2, or 93.75%. Therefore, the chance of at least
| one out of a sample of five being above the median and at
| least one being below is 93.75% (round it down to 93% or even
| 90% if you want to be conservative).
| chrisseaton wrote:
| Right so _random samples uniformly taken across the whole
| set of a finite set of independent samples_ is the first of
| the extra constraints you didn 't mention... which makes it
| not useful for many real-world computer-science
| applications like benchmarking, where you often have
| samples that are inter-dependent and from an infinite set
| so you can't sample them uniformly.
| shoo wrote:
| There would at least be an assumption that the samples are
| drawn independently from a single distribution, and the
| estimate of the median is for that same distribution.
|
| In the example you gave, the samples you draw are from the
| distribution of (the speed of your car just as it is setting
| off). There would be no guarantee that the estimated median
| has any relationship for any other distribution, such as
| (speed of your car during a trip). If you want to estimate
| the latter you'd need to figure out a way to draw random
| samples from that distribution.
| chrisseaton wrote:
| Can you do this with a source of infinite samples? If every
| time I take a sample it's slightly higher, does this still
| hold?
| lpolovets wrote:
| It's been about 20 years since I read this, but for people
| interested in quick mental math, here's a great book on doing
| fast calculations in your head: Dead Reckoning: Calculating
| Without Instruments
| https://www.amazon.com/dp/B00BZE4916/ref=cm_sw_r_tw_apa_i_Yu...
|
| IIRC it covers everything from multiplication to square roots to
| logarithms.
| MiguelVieira wrote:
| See also Street Fighting Mathematics
|
| https://ocw.mit.edu/courses/mathematics/18-098-street-fighti...
| noident wrote:
| I can't find a way to contact the author, so I'm just going to
| post this here: your RSS feed has broken links, it links to
| www.robertovitillo.com, but the www subdomain does not resolve to
| your site.
| gmcabrita wrote:
| Simon Eskildsen has a monthly newsletter called Napkin Math[0]
| entirely dedicated to practicing practical real-world Fermi
| problems like these.
|
| [0] - https://sirupsen.com/napkin/
| pulkitsh1234 wrote:
| Can most people do these calculations in their head?
|
| Personally I find that I am unable to do these
| calculations/estimations unless I write things down. I get lost
| between powers of 2/MB/TB/nanoseconds and other unit conversions.
| I understand that this is elementary math, but still, I am just
| curious, can most people do similar calculations in their head
| (for instance during a meeting) ?
| physicles wrote:
| I think it probably helps to know units and powers cold, so you
| can use your short term memory for the actual calculation. I
| was able to do the first calculation in the article because, as
| it says, it's just summing exponents on powers of 10. It should
| be second nature that M=6, G=9, T=12, or that "nano" means -9.
|
| Powers of 2 are incredibly helpful too: I can estimate that the
| square root of 4000 is around 60 because 4000 is close to 2 to
| the 12th, for instance. As a coder it's well worth your time to
| memorize powers of 2 up to at least 2 to the 16.
| comradesmith wrote:
| Further its good to think of your powers of 2 like: 10, kilo;
| 20, mega; 30, giga;
|
| And for 0-9 I have those memorized. So if I'm given the
| number 2^39 I unwrap that as 512 giga, or just over 500
| billion (seems its ~550, but estimating with base 2 is still
| going to be closer than estimating with base 10)
| stormdennis wrote:
| Working out loan repayments. If you borrow 100k over 20 years
| then roughly you'll be paying interest on 50k every year. If the
| rate is 8% then that's 4k in interest every year. You'll be
| paying back roughly 5k of the loan every year, so your annual
| repayment well be 9k a year or 750a month
| saagarjha wrote:
| (Keep in mind that due to how compounding works, averaging
| interest in this way will underestimate it slightly.)
| JadeNB wrote:
| > If you combine the rule of 72 with the powers of two, then you
| can quickly find out how long it will take for a quantity to
| increase by several orders of magnitudes.
|
| This seems to me like good but dangerous advice. I'm all for
| using back-of-the-envelope estimations as "small angle
| approximations" where they're not far off, but, in general,
| iterating the lossy approximation to get a large-scale answer is
| the wrong thing to do. It works well here, but only because we're
| dealing with logarithms, which genuinely _do_ convert
| multiplication to addition, and not mentioning this point seems
| to tempt one to use it in situations where it 's not applicable.
___________________________________________________________________
(page generated 2020-05-23 23:00 UTC)