>>okamiu+Pe
For interest sake, it looks like non-decimal reference values have been used https://en.m.wikipedia.org/wiki/Order_of_magnitude

>>pantul+Fb
Aerospace says π, but they do separate normalization of time and costs:

> 29. (von Tiesenhausen's Law of Program Management) To get an accurate estimate of final program requirements, multiply the initial time estimates by pi, and slide the decimal point on the cost estimates one place to the right.

https://spacecraft.ssl.umd.edu/old_site/academics/akins_laws...

>>behnam+(OP)
Two points to elaborate, already mentioned in the neighbour thread on estimation.

Firstly, programmers are notoriously and famously bad at estimation, so it's highly likely that you do need to find the multiplier for yourself. This illustration is something like fifteen years old by now: https://pbs.twimg.com/media/EyNRiYQXMAIshEj.jpg

Secondly, wise managers know to expect this, and do the multiplication themselves. But if you have managers who do the opposite and always scale the estimation back, expecting the results earlier that promised, then you need to use a second multiplier—which the manager will unknowingly annul, getting closer back to your actual figure. Probably something around 1.5 to 2.

However, if you need the second multiplier then you also gotta ask yourself why you're staying in that company.

>>behnam+(OP)
One method of estimating projects is using the old method Activity Based Costing. This can be used to estimate time-related activities as well. The key is figuring out your total utilization of time cost estimates and per unit of time cost drivers.

https://hbr.org/2004/11/time-driven-activity-based-costing

>>kqr+9J
I've been finding this approach incredibly useful too with teams and trying to manage the needs and concerns of business vs product vs engineering. I quite liked how it's described here: https://spin.atomicobject.com/2009/01/14/making-better-estim...

>>andrea+0y
I think this is the article that you’re recalling: https://erikbern.com/2019/04/15/why-software-projects-take-l...

>>teloto+Zd
this is not exactly true; here's some additional context for the curious:

https://www.purplemath.com/modules/bibleval.htm

https://answersingenesis.org/contradictions-in-the-bible/as-...

>>kqr+9J
> An estimation has two components: location and uncertainty

ReRe's Law of Repetition and Redundancy [5] could benefit from a refinement that accounts for the inverse relationship between width-of-delivery-window and certainty-of-delivery-date... maybe:

  A programmer can accurately estimate the schedule for only the repeated and the redundant. Yet,
  A programmer's job is to automate the repeated and the redundant. Thus,
  A programmer delivering to an estimated or predictable schedule is...
  Not doing their job (or is redundant).

[5] https://news.ycombinator.com/item?id=25826476

>>KingOf+nw
I've found this "story" by Michael Wolfe [1] (warning: Quora link that you may need to open in an incognito window) to be a fun way to explain why accurate software estimation is so difficult.

[1] https://www.quora.com/Why-are-software-development-task-esti...

>>kqr+9J
I still don't understand why Spolsky's Evidence Based Scheduling didn't get much traction. Defining the completion date as a range of probabilities makes the most sense.

https://www.joelonsoftware.com/2007/10/26/evidence-based-sch...

As implemented in Fogbugz:

https://fogbugz.com/evidence-based-scheduling/