3 ms·

I totally oppose this. Sometimes there are to many unkowns to give an estimation. Its better to NOT estimate because it doesnt hold any values. 'finished on ti

by TeeWEE 10y ago

I totally oppose this. Sometimes there are to many unkowns to give an estimation. Its better to NOT estimate because it doesnt hold any values. 'finished on time'.... This is the waterfall approach. Its broken in its core. So i also disagree with that.

yitchelle 10y ago
Sometimes, the time estimate that is put down on paper does not really matter at all. The estimate will force the engineer to think through their planning rather than just doing things adhoc.
lojack 10y ago
> Its better to NOT estimate because it doesnt hold any values. This is the core of where I disagree. Giving estimates provide tremendous value to those who depend on your work. It allows them to plan and forecast future needs. You're rarely ever working in some kind of bubble where your work is this mysterious thing that can be done tomorrow or in 4 years. I've never encountered a situation where there's so many unknowns that you can't come up with some number. Requirements change, timelines change, that's all fine. Businesses should be able to adapt to change. Being in the complete dark is much worse. > 'finished on time'.... This is the waterfall approach. I'm not sure what you mean by that? Things can't be late just because you're "agile"?
- namenotrequired 10y ago
  > I'm not sure what you mean by that? Things can't be late just because you're "agile"? I think TeeWEE means that in modern practice a product isn't "finished", it is launched but continually improved afterwards.
  - lojack 10y ago
    And to that (I know, not your words) I'd say he's incorrectly making the assumption that projects and products are synonyms, when they aren't. Projects are completed all the time, even in Agile.
EliRivers 10y ago
The only place I ever worked that delivered on time, within budget, with zero bugs reported from the customer, used waterfall.
HeyLaughingBoy 10y ago
Think of the biggest task you've ever completed. Now imagine we go back in time before you started and I asked you: will this take closer to one month or 10 years? Can you estimate that?

by TeeWEE 10y ago

yitchelle 10y ago

Sometimes, the time estimate that is put down on paper does not really matter at all. The estimate will force the engineer to think through their planning rather than just doing things adhoc.

lojack 10y ago

> Its better to NOT estimate because it doesnt hold any values. This is the core of where I disagree. Giving estimates provide tremendous value to those who depend on your work. It allows them to plan and forecast future needs. You're rarely ever working in some kind of bubble where your work is this mysterious thing that can be done tomorrow or in 4 years. I've never encountered a situation where there's so many unknowns that you can't come up with some number. Requirements change, timelines change, that's all fine. Businesses should be able to adapt to change. Being in the complete dark is much worse. > 'finished on time'.... This is the waterfall approach. I'm not sure what you mean by that? Things can't be late just because you're "agile"?

namenotrequired 10y ago
> I'm not sure what you mean by that? Things can't be late just because you're "agile"? I think TeeWEE means that in modern practice a product isn't "finished", it is launched but continually improved afterwards.
- lojack 10y ago
  And to that (I know, not your words) I'd say he's incorrectly making the assumption that projects and products are synonyms, when they aren't. Projects are completed all the time, even in Agile.

EliRivers 10y ago

The only place I ever worked that delivered on time, within budget, with zero bugs reported from the customer, used waterfall.

HeyLaughingBoy 10y ago

Think of the biggest task you've ever completed. Now imagine we go back in time before you started and I asked you: will this take closer to one month or 10 years? Can you estimate that?