Heya Guys,
Most Software Developer beliefs there are two hard problem that exists: [https://martinfowler.com/bliki/TwoHardThings.html]
1st one is how to Name things correctly.
2nd one is to invalidate cache.
But there exists a more dangerous hidden problem that creep out once you start growing in terms of team size, i.e. how do you estimate the time requires for a development of any feature.
From my experience it is totally subjective and depends upon the experience and on your technical debt,so keeping them aside I want to know how you guys estimate any development process and what according to you work or will not work.
What are the best practices to do this so that neither the dev feels frustrated & overburdened and nor the management feels too bad about it.
@rfornal , love to listen your views.
Top comments (1)
So, I'm a Product Manager. Which means I want to explain this problem from the other side of the table.
I agree estimates are hard. They are subjective. They are almost never accurate. My reason for asking for estimates comes down to four simple things (that can have greater or less importance in different companies)...
I want to understand if the cost of the project is going to be more or less than my perceived value of the project. Where cost is a function of time and people doing the work. If I am selling your work to a client, I want to understand what I should charge for it to make sure we make money. If I am not selling your work to a client, I want to make sure the feature is adding enough value to the product to make it worth our time. Over time and experience, I will learn how accurate your estimates are add a factor to them. Some of my favorite developers I have had a consistently multiplied their estimates by 2 or 3. Simply because I understand them.
JINWAS: Juice is not worth a squeeze. Similar to number 1 above but more about the tradeoffs between different approaches. If I am a good PM I have a number already in my head. Knowing if your number is significantly different may cause me to decide not to go down that feature path or to have some broader conversations about the overall feature. In those conversations we might find approach A is less "expensive" than approach B with a similar outcome for the users. We only get to that discussion if we discuss those costs.
I want to create discussion within a group. If I am seeing a group of engineers aren't getting much into the weeds on how they are going to approach a feature, I might ask they to do a quick estimate. In this case, talking about how much time it will take to build something will force you to talk about how to build it. That will force you to break it down into smaller pieces and get on the same page. That will mean we have a better idea of what we are building and why and be more on the same page on the feature.
I need to have some kind of project plan in order to plan work. I need to know how soon before they are going to need the next project often because I am working with multiple teams and I have designers to coordinate with. Pure, simple, project management.
So here's the thing. If someone asks me why I am asking for an estimate, I am going to tell them one of these three things and then I am going to play this game with them...
Me: Is it longer than a week?
Them: On goodness yes
Me: Is it longer than 6 months?
Them: No! If it takes me that long fire me.
Me: Longer than a month?
Them: I mean around there
Me: Longer than two month?
Them: No, I think closer to a month
Me: Great, I am going to write down two months for anyone external, and make sure I have the next project lined up for a month from now
That is more often than not the level of precision I need. If I need more precision than that, that is a different conversation.