Uhhhhhhhhhhh....
Shopping list is set and I should be in and out in 15 mins but it turns out there is no ketchup - so do I go to another store to get ketchup or mustard will do. Product owner my Girlfriend has to decide because she is doing the cooking and will present it to customers our guests, and she knows if they like mustard or not because she talks to them more often than I do.
But yeah going to another store might make dinner late and I cannot know this until I actually arrive at the store that there is no ketchup on the shelves.
Of course there could be a fire on-route causing a jam that turns your 15 minute trip into 2 hours, but that's sufficiently unlikely it's probably not worth building into your estimate (but could be depending on the stakes involved! If someone is going to die you should probably factor this in so we can plan for that contingency). In that instance instead you need to communicate when it happens so that everyone involved can recalibrate.
Yeah, I had a PM who taught me to do this by doing it themself. My estimates are actually just doubled from how much I expect it to take when I know the design and can work with no distractions.
I’ve also worked with managers who “negotiate” as others sometimes describe. Of these I see good and bad. One who was aware of short- and long-term goals of our team and asked for estimates so they could decide what features we need to include; another who already promised the features and the deadline and is asking me to tell them that they did not overpromise despite my observations. (“I don’t believe I’ll be able to deliver those features by that date.”)
Others in between, including some who don’t like being told explicitly that I double the estimate. Worse still, the one who halves it as if to correct for some mistake.
I guess the moral is that developers aren’t the only critical party when it comes to communicating estimates. Managers do their own job; good, bad, or otherwise.
-------
> depending on my audience
Other than some managers I assume another developer or a good technical manager, and it’s a good approach. Sounds at least similar to explicitly stating that you doubled your “no distractions” estimate. Too bad it seems that an unfortunate lot of people work with the bad “negotiating” type who might even be so disrespectful as to correct their co-worker’s mistaken opinion -- which they asked for!
(Not to leave this as advice for the parent commenter. Just wrote some thoughts and figure I can share for anyone who might get value from them.)
No one writes down "this is why I think the project will take X [time units]".
And no one goes back to that estimate and says "I left Y & Z out of that estimate, I better include that next time."
If you want estimates that have any relation to reality, your estimating process needs to have that sort of feedback.
> When people saying that estimating is hard...
I think they're referring to the sort where management negotiates the estimates, like you're haggling over something in the marketplace. If they have such a strong opinion about how long something should take, then asking you for estimates is setting you up for failure and blamestorming. "It’s one banana, Michael. What could it cost, $10?"
Also, on the negotiation side of time it will take, I absolutely know for myself that I can code things fast and functional but a bit hacky, or beautiful and elegant and will take much longer.
The negotiation should be about when to do which.
At a higher level, you put your teams together within their temperaments in mind and match that to the work.
Some code will be a nexus of changes and interaction with other code (invest early), and some code will get written once and never seen again (go fast and forget).
The issue is that there's a fluidity in that thinking that many many MANY technical people either don't have or don't employ.
As for negotiating estimates down, it is up to technical leadership to refuse to do that. Not easy, but doable.
It's like calling a mechanic over the phone and asking how much it will take to fix your car. The mechanic doesn't know if the engine just fell out of your Model T or if you're just trying to put the key in backwards. How about you bring it in first, then we'll look it over and go from there?
Sometimes you can ask some questions and get to, "Well it's probably X which would take Y but we'll need to see". Then they get Y stuck in their head and it turns out to be the one time out of twenty when the cause isn't actually X but something much more involved.
Really, you just have to be a pessimist. Instead of saying what people want to hear (it's simple and can be implemented quickly), you need to imagine the long-tail worst-case scenario where everything that can possibly go wrong goes wrong, then give that number. If people don't give you a somewhat incredulous look when you give an estimate, you probably were too optimistic. Just remind them that you're imagining a worst-case scenario and say that you hope to have it done sooner, but don't back down on your estimate.
Another thing to realize: at the business level, deadlines are often picked arbitrarily to create urgency. The specific date of the deadline is usually less important than just having some deadline, any deadline, to motivate everyone. Business people will pretend the deadline is Very Important, but it's all an act, more or less (arguably it's a necessary one). Remember this when giving your estimates.
disagree, not all tasks can be estimated accurately depending on circumstances but this does not imply that it's impossible to estimate any task accurately.
Maybe it’s just a quick CSS change, but all of a sudden the webpack build starts mysteriously failing. And now your node_modules got corrupted and oops, when you delete it and reinstall dependencies, there’s a dependency conflict. Once you’ve finally gotten that figured out, some tests are now failing in part of the codebase you’ve never seen before. Better make some coffee…
Some version of this can always happen, and as a task gets larger, it is almost guaranteed to happen multiple times in multiple variations. Since you don’t know what problems will arise, there is no way to know how long it will take you to fix them. You can stay up all night in order to pretend that your “quick and easy” estimate was accurate, but that only takes you so far.
What if, while cooking dinner, a meteor crashes in my kitchen and so my estimate of 30 minutes to cook dinner turns out to be incorrect? That _obviously_ means the conclusion is that it's impossible to accurately estimate how long it takes to cook that dish so we should never do so.
There has to be a name for the type of reply your post represents.
This ends up coupled with the fact that practitioners (of anything productive) tend to think in terms of 50-ish percentile estimates (i.e., there's a 50% chance this project is done in this amount of time), whereas business people care about 90th-99th percentile estimates. In software, the difference between between a 50th percentile estimate and 90th percentile estimate can be more than an order of magnitude in time spent.
If your shit is breaking so often it's affecting your willingness to estimate, that's a you problem.
I'm driving to another state for the thanksgiving holidays, and I have an estimate for how long that will take. Is it possible when I walk out to my car that the battery died the night before? sure. Am I going to factor such an unlikely event into my estimate? no. Does that imply it's impossible for me to accurately estimate how long that trip is going to take? No it doesn't.
Only in software could someone be using a tool that constantly doesn't work and they never consider replacing it or fixing it. Imagine if a carpenter showed up to your house with a hammer whose handle fell off once or twice an hour but they expected you to pay them for the loss of productivity rather than purchasing a hammer whose handle doesn't fall off.
That produces a much fatter tail distribution, because you're doing someone that no one has ever done before, and thus no one knows exactly how long it's going to take.
odd, because my experience is that your CI/CD pipeline does the exact same thing repeatedly.
Perhaps the answer to your confusion about my experience is that I don't suffer tools that hamper my productivity.
Put it another way.
I ran a raiding guild for several years and about halfway through that stint I recruited a player that raised the bar for what I thought was possible. Perhaps you need your bar raised.
Both have been documented to have happened, yet somehow you didn't seem to think that should be taken into account when considering estimates for cooking and pissing.
If your shit is breaking so often you're afraid to give an estimate, that's a you problem.
And yes, we had an internal team that w/i the last 6 months couldn't go a week without a deployment problem. Ask me why they no longer have that issue.
This is too real.
Which is why you'll get better at estimating as you get more years of experience under your belt, and why estimating is something that seniors are better at than juniors.
Even after 20 years you may never have hooked in new library X, but I'd be willing to bet you've done something kind-of similar, and your estimate will be more accurate than a person with 1 year of experience and has never done anything remotely similar.
> Estimating things you've done a lot is trivial, and pointless.
Keep in mind you are not providing the estimate for the person who has done the task many times, you're providing the estimate to people who have never done it before. So for them, it absolutely is not trivial.
Estimating things you've never done is hard.
Estimating things you've done a lot is trivial, and pointless.
When people saying that estimating is hard, they don't mean they easy kind.