Always, always, with every estimate in time or resources you or your pm/manager/whatever thinks to need. Multiply that number by pi.

That's a more real-world estimate.

Honestly idk but that one chapter from mythical man month, "Plan to Throw One Away", stuck with me:

"Where a new system concept or new technology is used, one has to build a system to throw away, for even the best planning is not so omniscient as to get it right the first time."

In my current project I've seen this play out, initial development was very prototype-ish and just not well designed but when we got a somewhat decent state we had to continue with it instead of starting again and doing it properly. And now the consequences of that are hitting, progress for new features is incredibly slow, the software is very error prone, a bunch of dead code all around, ...

* break it into elementary steps, small enough to fit into your "estimation time unit", e.g. days or hours.
* estimate those steps for "developing at a leisurely pace" if nothing goes wrong.
* think about "what could go wrong" (list everything!) and adjust values accordingly.
* adjust total amount with experience values, like:
* times 1.2 for every manager
* times 1 to 4 based on which legacy projects i have to touch

and finally:
* multiply with `1+log(t/u,2)`, with `u` being the amount of useful data in the requirement description and `t` being the total amount of data in the requirement description
* sample: with our current "favourite" customer, about 90% of all tickets is garbage, so t/u = 100/10 = 10 => log(10,2) = 3.3 => multiply everything with 4.3

It's all based on the dev's experience. A beginner always faces trouble estimating a feature/project, but seniors don't, cuz they have the experience to get over the hurdles in software development.

(Time to actually code feature + time to debug it + time for unit tests to pass/add) * 1.5

Works great in my case unless there are some big major road blocks

Always estimating for the best possible, quality solution. I refuse to write anything less than perfect. Also I estimate the time based on how I feel that day lol.

White Bird in a Blizzard. Definitely my favorite movie even though it’s so sad as it reminds me of my own life

Best way to estimate a dev project for me is to establish what are the nice to haves and the must haves. A lot of times I’ll get a big list of requirements or a vague outline, so I need to figure what are our priorities.

If the project involves a new service that we have to purchase, then that project’s time estimate is one weekend because that’s how long it took other companies to implement per that service’s account manager lol 🤣