
Back of the envelope estimation hacks - bkudria
https://robertovitillo.com/back-of-the-envelope-estimation-hacks/
======
kthejoker2
Three other hacks which when combined have a lot of power ..

Chebyshev's Theorem: 89% of all values in (almost every human-ish)
distribution fall within 3 SDs of the mean.

PERT estimation: base your estimates on the happiest (O for optimistic)
unhappiest (P For Pessimistic), and most likely (ML) path - the recommended
formula is (P + O + 4ML) / 6, but you can also just model them as a
distribution.

Secretary problem: when attempting to optimize a result, the effect of
uncertainties can be ascertained in 1/e (~37%) of the total solution space.

So putting this together ..

If you have to give a time estimate for something, your best bet is to

1) get your 3 PERT numbers

2) calc the mean, SD, and 37% of mean + 3SD ("Assessment") - this is how much
time it should take (based on your pessismism) to eliminate uncertainty for
the remaining work estimate

3) if the mean is less than the Assessment time, there's too much uncertainty
and you should offer to assess the effort instead of just doing the work

4) if the mean is more than the assessment, just offer to do the work with the
PERT output from the formula above.

I find most people are happy to hear you have a concrete plan for assessing
something with the explicit purpose of providing precision.

------
DavidPeiffer
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
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
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
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
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?

------
MiguelVieira
See also Street Fighting Mathematics

[https://ocw.mit.edu/courses/mathematics/18-098-street-
fighti...](https://ocw.mit.edu/courses/mathematics/18-098-street-fighting-
mathematics-january-iap-2008/)

~~~
borski
Came here to post this. I took his course as “The Art of Approximation in
Science and Engineering” and absolutely loved it. So much so that it became
the name of my CTF team for the next few years.

------
qznc
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
> 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.)

~~~
shoo
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
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?

~~~
shoo
> If every time I take a sample it's slightly higher, does this still hold?

I don't know enough stats to give a firm answer, but I'd reckon there is a key
assumption that the samples need to be drawn i.i.d. from a single underlying
probability distribution, or perhaps need to satisfy the related assumption of
being exchangeable.

[https://en.wikipedia.org/wiki/Independent_and_identically_di...](https://en.wikipedia.org/wiki/Independent_and_identically_distributed_random_variables)

[https://en.wikipedia.org/wiki/Exchangeable_random_variables](https://en.wikipedia.org/wiki/Exchangeable_random_variables)

In your example of a sequence of samples that increase, they're certainly not
exchangeable. I think they're not independent either.

E.g. thought experiment to give a concrete version of your example, where we
define it so there's no randomness at all to make it easier to think about :
let's suppose an idealised situation where we launch a space probe that
travels away from the earth at 15 km / second. Suppose we have some way of
measuring the distance d(t) that probe is from earth at some time t after
launch. Regard each distance measurement d(t) as a sample. Let's assume we
take 5 samples by measuring the distance every 10 seconds after launch. So
t_1=10s, ..., t_5=50s, and d(t_1)=150km, ..., d(t_5)=750km.

The sequence of distance samples d(t_1), d(t_2), d(t_3), d(t_4), d(t_5) is not
exchangeable as if we exchange two samples like d(t_2) <-> d(t_4), the
permuted sequence d(t_1), d(t_4), d(t_3), d(t_2), d(t_5) corresponds to the
situation: "at 10 seconds the probe was 150 away, at 20 seconds the probe was
600 km away, at 30 seconds the probe was 450 km away, at 40 seconds the probe
was 300 km away, at 50 seconds the probe was 750 km away" \-- the probability
of observing that outcome is an awful lot lower -- based on our understanding
of how physics of the situation work in this idealised example -- than the
probability of observing the outcome from the original sequence (this is
pretty sloppy as I am not clearly distinguishing between observed values and
random variables, but hopefully it gives some vague intuition).

So if you want to estimate the median distance of the probe from the earth
from 5 samples, you roughly need to take 5 measurements at 5 times chosen to
be uniformly at random from the entire period you are interested in. E.g. if
you want to estimate the median distance of the probe from the earth during
the first 10 years of travel, you need to draw 5 samples from 5 different
times sampled from the uniform distribution over the period [0 seconds, 10
years]. Then the resulting estimated median distance would only apply for the
distance of the probe during that time period, it would not be an estimate
that could be applied for any different time period.

~~~
chrisseaton
> a key assumption that the samples need to be drawn i.i.d. from a single
> underlying probability distribution, or perhaps need to satisfy the related
> assumption of being exchangeable

Unfortunately this kind of key assumption is rarely made explicit when
teaching people stats. I see research papers all the time making this
assumption where it clearly isn't warranted - such as in benchmarking a
computer.

------
saeranv
Here's one that I learned from HN years ago
([https://news.ycombinator.com/item?id=18463449](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
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

~~~
contravariant
It should also be pointed out that the one thing you're ruling out is that
they have the same distribution.

In particular it only provides weak evidence that the mean, mode, median of A
is any faster than B's. In the worst case A happens to be _a lot_ slower than
B, but with very low probability.

------
JadeNB
> 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.

------
heipei
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
Edit: I stand corrected.

365.25 / 12 * 24 = 730.5

Technically it is 731 if you round up.

~~~
mitjam
365 * 2 = 730 :)

~~~
pdonis
There aren't exactly 365 days in a year.

~~~
_1100
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.

~~~
pdonis
_> We understand nothing “exactly” in this universe_

Apparently a lot of "we" don't, since a number of people were saying they did
the "exact" calculation that kolanos did but got a different answer.

 _> so maybe cool it on the fun fact witch hunt.?_

The "witch hunt" seems to me to be on the part of the people who downvoted a
perfectly correct and legitimate post, and those who responded to it with a
claimed "exact" calculation that was wrong.

------
lpolovets
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...](https://www.amazon.com/dp/B00BZE4916/ref=cm_sw_r_tw_apa_i_YuzYEbHK0KR6P)

IIRC it covers everything from multiplication to square roots to logarithms.

------
noident
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.

~~~
redblackbit
Whoops, thanks!

------
pulkitsh1234
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
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
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)

------
londons_explore
The quickest way to get good at this is practice.

Just ask engineer friends random questions from time to time, and when there
is no consensus, calculate the results properly.

Eg. How much power could a solar powered fly collect?

How many tons of batteries would I need to drive a train across the USA?

How long can I power my laptop from a solar usb battery bank in the sun each
day on a hiking trip?

What's the load time of this webpage I just wrote on a satellite internet
connection?

How long would it take to boot up my OS if I could keep RAM intact during a
reboot?

How many kilos of coal does it take to cook a pizza?

------
yongjik
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...)

------
alexpetralia
When tipping, I realized it's harder for me to multiply the bill (say $58)
times 15% rather than times 30% / 2\. In the latter case I simply do 60 * .3 /
2 which is $9. I thought about this after realizing, for example, that 18 * 5
is really 18 * 10 / 2.

Edit: just realized this is more about mental math than about back-of-the-
envelope estimations

~~~
bcrosby95
I usually just do something with 10s. I usually tip 20% so i knock off a zero
then double it.

If I tipped 15%, I would probably knock off a zero, then add half to it.

------
hoorayimhelping
A post with some examples: [http://highscalability.com/blog/2011/1/26/google-
pro-tip-use...](http://highscalability.com/blog/2011/1/26/google-pro-tip-use-
back-of-the-envelope-calculations-to-choo.html)

------
gmcabrita
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/](https://sirupsen.com/napkin/)

------
RcouF1uZ4gsC
Another neat hack for estimating lower limits on latency is that light travels
roughly 1 foot in a nanosecond.

So if two servers are in a room 100 feet apart, the time it takes for them to
communicate cannot be lower than 100 ns.

------
basementcat
A large hamburger contains approximately one kilowatt hour worth of
kilocalories.

------
stormdennis
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
(Keep in mind that due to how compounding works, averaging interest in this
way will underestimate it slightly.)

~~~
stormdennis
Yes but the point is that it's just a back of an envelope estimate. I'm amazed
that it's been downvoted as it's actually a technique that's used in this way
all the time, or at least was anyway. I don't know about now when everyone has
a smartphone.

