Why software projects take longer than you think – a statistical model
&gt; Instead, figure out which tasks have the highest uncertainty – those tasks are basically going to dominate the mean time to completion.<p>From the <i>technical</i> side of things, uncertainty can mean a few things here:<p>(A) I&#x27;ve never done this kind of task (or I don&#x27;t remember or didn&#x27;t write down how long this task took in the past)<p>(B) I don&#x27;t know how to leverage my historic experience (e.g., implementing an XYZWidget in React and implementing the same widget in Vue or Elm for some reason take different amounts of time)<p>Considering (A)... <i>Rarely</i> does a seasoned developer in the typical business situation encounter technical tasks that are fundamentally different than what has been encountered before. Even your bleeding-edge business idea using modern JS&#x27; + GraphQL&#x27; is still going to be built from the same <i>fundamental</i> pieces as your 1999 CRUD app using SOAP and the estimates are going to be the same.<p>If you disagree with this you are in the (B) camp or you haven&#x27;t done the work to track your estimates over time and see how ridiculously accurate estimates can be for an experienced practitioner. Even &quot;soft tasks&quot; like &quot;design the widget&quot; are estimable&#x2F;repeatable.<p>This whole you-can&#x27;t-estimate-software accuracy position is entirely a position of inexperience. And of course all bets are off there. You are talking about estimating <i>learning</i> in this case, not <i>doing</i>. And the bets are especially off if you aren&#x27;t modeling that these are two different activities: learning and doing.