Introduction
I recently interacted with a friend who had just started out as a developer and she told me that she found it really hard t...
For further actions, you may consider blocking this person and/or reporting abuse
Pro tip: guess, double it, add some more. Then be prepared to be waaaay off still.
If it's a sales person wanting the estimate, triple it. They are going to take some off anyway and put you under pressure
Doubling it has worked really well for our teams. We've been able to meet schedules that way.
It's because people either over estimate their ability, or underestimate the work required. Usually both.
yes it also equals out over many people
but always better to be pessimistic
It's also because even if you know exactly what to do.. you do it in the estimated time, but then the customer asks for 3-4 changes afterwards.. so that doubles the time as well. Also bugs.
Hahahaha.. thanks for sharing 😃
Simplest and best thing to do is not to estimate. Check out the discussion here: dev.to/carmenhchung/how-to-nail-ti...
I tend to agree but usually provide clients with a ballpark range. I explain that the low number is the minimum effort required and the top one is with some nice features like x and x. As for junior devs estimating, I don’t expect them to. I quote the project for how long it would take me and then don’t bill all of the devs hours since they don’t move as fast as I can. As they speed up, I can start increasing their pay for projects.
Thanks for reading my article and sharing your thoughts. Cheers!
If you do not estimate, then how do you learn to estimate?
Your question answers itself - if you don't estimate, you don't need to learn how to.
After a while you will just know instantly for some small known tasks how long they will take. That is not an estimate. For bigger unknown tasks, estimation is futile and purely a waste of time
But sadly, the larger industry doesn't work that way. In an ideal world, I'll agree with you. But, having 16+ yrs experience in various types of firms such as enterprise, product and startup industry, providing estimates is fundamental part of building software. If you say, it's not. Then it's an exception the norm. We'll have to agree to disagree on that.
25 years of experience in similar industries says otherwise, but maybe I just do things differently
Thanks for reading and wish you the best!
In fact, I went through the comment chain in your posts. Most of what I would have wanted to counter is covered there. But still, you commented in this section, means you want more views for your content 😎🙌 and I'm cool with that.
I do estimation in about 30% of my working time (it's just an estimation, too :) ), from trivial 0.5hour tasks to several hundred hours projects (client expects everything to be estimated for capacity and scheduling purposes). Sometimes I can use more precise approaches, N blocks x M hours + some slack, testing, communication, etc, sometimes I have to bluff something because noone has any idea how long the task will take, simply there are too many unknown factors (technical or something else). Sometimes I have to send my estimates to be reviewed by other senior teammates. Usually the outcome is OK, we are in an acceptable limit, but sometimes things don't go well. It happens and we have to handle it somehow.
100% can relate to it. Just like everything else in life, we learn based on our experiences and I've seen senior developers also struggle in areas that they hadn't worked before for providing estimates. Like you said, sometimes it's an educated guess. Sometimes, it's about breaking things down and adding values against it. Thanks for reading ☺️