4 ms·

My big point is: - If you don't know what you are doing or you are doing for the first time, there's no point in estimate as your estimations will be off anywa

by islon 12y ago

My big point is: - If you don't know what you are doing or you are doing for the first time, there's no point in estimate as your estimations will be off anyway. - If you know what you are doing and already did it before, there's no point in estimate as you already know how much time it'll take.

peshkira 12y ago
In my opinion these two points only hold if you work alone. As I see it, you don't estimate for yourself, you estimate for transparency, so that other team members can plan accordingly. In your first point, you might not be able to estimate, but others might be able to do so and give you hints. Your final estimation might still be off, but that's how you learn. In your second point, you estimate so that others can see how long it will take and plan their work better.
timv 12y ago
If you know what you are doing and already did it before, [...] you already know how much time it'll take. So you've estimated it then? If the argument is that we spend too much time producing detailed estimates that don't actually reflect reality, then I agree. If you're suggesting that a sensible way to run a business is to say "I have absolutely no idea how long this will take, and how much it will cost, but let's do it anyway" then that's crazy. Even the team as Wesabe (in the article) are estimating - He does encourage his developers to spend most of their time working on things that they can finish quickly and When they need to, Wesabe developers will tackle bigger projects. You can't distinguish "finish quickly" from "bigger projects" without estimating. It may be the quickest easiest form of estimating "big or small", but it's still an estimate. The reality of the argument is that a lot of organisations can make do with a lot less formality and rigour in the estimation process. Moving from "vaguely approximate" to "slightly more accurate" is an expensive process with all sorts of cultural side effects that too many people assume is "worth it" without any real justification. But we all estimate, because it's pretty rare that you can justify starting a piece of work that might take a day, or might take 10 years - I'll let you know when it's done.
- jacques_chester 12y ago
  I think that part of the problem is that when people say "estimate" in our profession, they're thinking of capital-E-Estimates. With a whole bunch of theatre and disruption and danger and political nonsense. It's not the informed prediction of the value of some unobservable variable that upsets us. It's the larger picture around it.
jiggy2011 12y ago
If you've already done it before it should take almost zero time because you just re-use your previous code!
jacques_chester 12y ago
My estimate is that you've created a false dichotomy to avoid the very large area between pure research and pressing a button, where estimation can provide value.

by islon 12y ago

peshkira 12y ago

In my opinion these two points only hold if you work alone. As I see it, you don't estimate for yourself, you estimate for transparency, so that other team members can plan accordingly. In your first point, you might not be able to estimate, but others might be able to do so and give you hints. Your final estimation might still be off, but that's how you learn. In your second point, you estimate so that others can see how long it will take and plan their work better.

timv 12y ago

If you know what you are doing and already did it before, [...] you already know how much time it'll take. So you've estimated it then? If the argument is that we spend too much time producing detailed estimates that don't actually reflect reality, then I agree. If you're suggesting that a sensible way to run a business is to say "I have absolutely no idea how long this will take, and how much it will cost, but let's do it anyway" then that's crazy. Even the team as Wesabe (in the article) are estimating - He does encourage his developers to spend most of their time working on things that they can finish quickly and When they need to, Wesabe developers will tackle bigger projects. You can't distinguish "finish quickly" from "bigger projects" without estimating. It may be the quickest easiest form of estimating "big or small", but it's still an estimate. The reality of the argument is that a lot of organisations can make do with a lot less formality and rigour in the estimation process. Moving from "vaguely approximate" to "slightly more accurate" is an expensive process with all sorts of cultural side effects that too many people assume is "worth it" without any real justification. But we all estimate, because it's pretty rare that you can justify starting a piece of work that might take a day, or might take 10 years - I'll let you know when it's done.

jacques_chester 12y ago
I think that part of the problem is that when people say "estimate" in our profession, they're thinking of capital-E-Estimates. With a whole bunch of theatre and disruption and danger and political nonsense. It's not the informed prediction of the value of some unobservable variable that upsets us. It's the larger picture around it.

jiggy2011 12y ago

If you've already done it before it should take almost zero time because you just re-use your previous code!

jacques_chester 12y ago

My estimate is that you've created a false dichotomy to avoid the very large area between pure research and pressing a button, where estimation can provide value.