5 ms·

I've been to the store before. A lot. I've never hooked in new library X to the codebase and implemented that new functionality. Estimating things you've nev

I've been to the store before. A lot. I've never hooked in new library X to the codebase and implemented that new functionality. 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.

orwin 3y ago
Estimate are for accountability. It's for team management. That's why middle management shouldn't have access to estimates imho.
- sixothree 3y ago
  The issue everyone is skirting here about estimates is the unknowns. Letting management know what the unknowns are and how confident you are you can resolve them is just as helpful as providing an accurate hour estimate.
Clubber 3y ago
"I want you to build a document management system, how long will that take?" Uhhhhhhhhhhh....
- saalweachter 3y ago
  "It will take me X weeks... to come up with a reasonably accurate estimate."
- guappa 3y ago
  It will take 2 months to gather the actual requirements and be able to do an estimate.
  - wheresthebeef 3y ago
    This guy consults.
    - rawgabbit 3y ago
      From my experience, the two months of gathering requirements will be more valuable than developing something from zero requirements. Whatever you code with always be "wrong" because with zero requirements there is nothing to test against.
- baq 3y ago
  the correct answer is 'yes'
- speed_spread 3y ago
  Fork an existing one, slap your name and logo on it. 2 points.
  - locustmostest 3y ago
    Exactly. We'd love it if more people did that with our document management system. (https://github.com/formkiq/formkiq-core https://github.com/formkiq/formkiq-core)
- Izkata 3y ago
  "This is git. Have fun!"
lcnPylGDnU4H9OF 3y ago
Even on the store point: I might notice I’m low on fuel and fill up on the way. Easily turns a 15-minute errand into 20 minutes. Estimations in the context of a software project are similar to a promise that my trip to the store will only be 15 minutes which I’m held to even if I notice the low fuel gauge.
- ozim 3y ago
  I like the store metaphor. 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.
  - interactivecode 3y ago
    Its a good metaphor also because if you have an appointment in 20min you would never go to the shop 15min before. Yet managers will force you still out and to the shop because of your time estimate.
- Volundr 3y ago
  Part of estimating is accounting for those contingencies. Given above, depending on my audience the above estimate will be either 30 minutes, or 15 minutes but could be as long as 30 depending on these factors. Part of estimating is accounting for the setbacks one can (reasonably) expect to see, to give the other party a timeframe within which they can be (reasonably) certain it will be done. 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.
Tangurena2 3y ago
I think the reason that estimating is hard is that no one ever returns to their estimates and tries to fix the estimates. What usually happens is that people throw out a number, mismanagers think that number is negotiable, and whether the project's completion is in any way related to the estimate - the estimate is forgotten. 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?"
- deleted 3y ago
  [deleted]
- SpaceNoodled 3y ago
  I've streamlined the process, and just say that anything will take five days to complete.
- sroussey 3y ago
  Teams definitely refine and alter estimates as new knowledge of the problem space is discovered. It’s a management (and team) failure if this does occur. 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).
- PH95VuimJjqBqy 3y ago
  One of the things that makes me so successful is that I always try and have a backup plan. "our goal is X, if we fail to meet that with approach Y then we'll use approach Z. Lets prepare for approach Z while we're also preparing for approach Y and evaluate and switch to approach Z as early as we possibly can. We still want approach Y so we'll continue working on it even if we start using approach Z to successfully launch". 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.
steamer25 3y ago
My favorite is being asked to estimate a bug fix before I've had any chance to analyze the issue. 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.
- vkou 3y ago
  If you're being asked to estimate a task without insufficient information on what the task is, punt it back with 'More information needed, we'll look at it 3 weeks from now in the next sprint planning'.
danenania 3y ago
Accurate estimates are impossible, but you can get better at them. Getting better at them mostly entails increasing your estimate to the point that it feels absurd, and then doubling it. To become a true expert, double it again. Another approach is to always bump it up a unit of time. So an hour becomes a day, a day a week, a week a month, a month a quarter, etc. 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.
- PH95VuimJjqBqy 3y ago
  > Accurate estimates are impossible 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.
  - danenania 3y ago
    No matter what the task is, things can go wrong that you didn’t anticipate. 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.
grecy 3y ago
> I've been to the store before. A lot. I've never hooked in new library X to the codebase and implemented that new functionality. 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.

orwin 3y ago

Estimate are for accountability. It's for team management. That's why middle management shouldn't have access to estimates imho.

sixothree 3y ago
The issue everyone is skirting here about estimates is the unknowns. Letting management know what the unknowns are and how confident you are you can resolve them is just as helpful as providing an accurate hour estimate.

Clubber 3y ago

"I want you to build a document management system, how long will that take?" Uhhhhhhhhhhh....

saalweachter 3y ago
"It will take me X weeks... to come up with a reasonably accurate estimate."
guappa 3y ago
It will take 2 months to gather the actual requirements and be able to do an estimate.
- wheresthebeef 3y ago
  This guy consults.
  - rawgabbit 3y ago
    From my experience, the two months of gathering requirements will be more valuable than developing something from zero requirements. Whatever you code with always be "wrong" because with zero requirements there is nothing to test against.
baq 3y ago
the correct answer is 'yes'
speed_spread 3y ago
Fork an existing one, slap your name and logo on it. 2 points.
- locustmostest 3y ago
  Exactly. We'd love it if more people did that with our document management system. (https://github.com/formkiq/formkiq-core https://github.com/formkiq/formkiq-core)
Izkata 3y ago
"This is git. Have fun!"

lcnPylGDnU4H9OF 3y ago

Even on the store point: I might notice I’m low on fuel and fill up on the way. Easily turns a 15-minute errand into 20 minutes. Estimations in the context of a software project are similar to a promise that my trip to the store will only be 15 minutes which I’m held to even if I notice the low fuel gauge.

ozim 3y ago
I like the store metaphor. 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.
- interactivecode 3y ago
  Its a good metaphor also because if you have an appointment in 20min you would never go to the shop 15min before. Yet managers will force you still out and to the shop because of your time estimate.
Volundr 3y ago
Part of estimating is accounting for those contingencies. Given above, depending on my audience the above estimate will be either 30 minutes, or 15 minutes but could be as long as 30 depending on these factors. Part of estimating is accounting for the setbacks one can (reasonably) expect to see, to give the other party a timeframe within which they can be (reasonably) certain it will be done. 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.

Tangurena2 3y ago

I think the reason that estimating is hard is that no one ever returns to their estimates and tries to fix the estimates. What usually happens is that people throw out a number, mismanagers think that number is negotiable, and whether the project's completion is in any way related to the estimate - the estimate is forgotten. 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?"

deleted 3y ago
[deleted]
SpaceNoodled 3y ago
I've streamlined the process, and just say that anything will take five days to complete.
sroussey 3y ago
Teams definitely refine and alter estimates as new knowledge of the problem space is discovered. It’s a management (and team) failure if this does occur. 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).
PH95VuimJjqBqy 3y ago
One of the things that makes me so successful is that I always try and have a backup plan. "our goal is X, if we fail to meet that with approach Y then we'll use approach Z. Lets prepare for approach Z while we're also preparing for approach Y and evaluate and switch to approach Z as early as we possibly can. We still want approach Y so we'll continue working on it even if we start using approach Z to successfully launch". 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.

steamer25 3y ago

My favorite is being asked to estimate a bug fix before I've had any chance to analyze the issue. 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.

vkou 3y ago
If you're being asked to estimate a task without insufficient information on what the task is, punt it back with 'More information needed, we'll look at it 3 weeks from now in the next sprint planning'.

danenania 3y ago

Accurate estimates are impossible, but you can get better at them. Getting better at them mostly entails increasing your estimate to the point that it feels absurd, and then doubling it. To become a true expert, double it again. Another approach is to always bump it up a unit of time. So an hour becomes a day, a day a week, a week a month, a month a quarter, etc. 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.

PH95VuimJjqBqy 3y ago
> Accurate estimates are impossible 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.
- danenania 3y ago
  No matter what the task is, things can go wrong that you didn’t anticipate. 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.

grecy 3y ago

> I've been to the store before. A lot. I've never hooked in new library X to the codebase and implemented that new functionality. 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.