Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
Search - "wk340"
Take the worst possible estimate you can come up with. Multiply by 3.
Usually ends up pretty close in my case at least.3
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.8
(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
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, ...10
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.
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.7
I just do the Three-point estimation method: It's easy enough to remember and somewhat scientific: https://en.wikipedia.org/wiki/...
I made a spreadsheet a while back which serves as a template. I guess nowadays there must be at least one website with a fancy diagram no doubt..1
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 🤣1
* 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
* 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