Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

As a dev who has quite some freedom managing himself, I learned to multiply my own estimates by about 2-2.5.

If I had a bad case of managers, I would probably multiply by four.



I remember one of Akin's Laws of Spacecraft Design being something like: take your original estimates, multiply the time by π and shift the decimal on cost one place to the right.


https://spacecraft.ssl.umd.edu/akins_laws.html

My favorite might be 31. (Mo's Law of Evolutionary Development) You can't get to the moon by climbing successively taller trees.


Also related: always multiply your estimates by pi https://web.archive.org/web/20170603123809/http://www.tuicoo...


I personally multiply by 3 for any process which isn't almost entirely automation.


3x fits pretty much every engineering project I've worked on.


Same. And this is also what I teach junior engineers to do. If there are any unknowns, double it to 6x. No one will be upset if you deliver early.


3 is about right.

What happens is that the difference between the estimate that management will psychologically accept to begin the project (and then commit to due to sunk cost fallacy) and the actual schedule is about a factor of 3.


You forget to factor in your own bias.

https://pbs.twimg.com/media/EyNRiYQXMAIshEj.jpg


There's a paper that gives an exact number: 1.7x. This is the average time it goes over estimates, for code and writing tasks. The other numbers seem better, but you should not go below 1.7.


electrical engineer + IT dev now here - literally every project I've taken part was 3x the estimate.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: