All estimates are wrong, what matters is improving their business value by making them more accurate.
That some estimates will be less accurate due to uncertainty is not by itself a reason to totally abandon estimating.
The generalised case of your argument is that estimation is imperfect in all cases, therefore, we must abandon estimation. This is known as the Nirvana Fallacy: "we have a partial, imperfect solution. Because it is not complete and perfect, it is worthless".
Even modest improvements in estimate accuracy can have enormous value.
By the way, estimating is not planning. An estimate is an estimate. A plan is a plan. They are different things.
Wasn't talking about uncertainty at all, so I'm not sure why that comment. And no, its not really cool to pretend I said something else so you can debunk that.
I'll repeat myself then: the task of diving into a problem to estimate its time is, for many problems, approximately equal to the time to solve the problem. And I honestly have a hard time figuring out a responsible approach in those cases.
> Wasn't talking about uncertainty at all, so I'm not sure why that comment.
Because you wrote:
> in software projects the country is not just unknown but potentially unknowable
Which is uncertainty.
> I'll repeat myself then: the task of diving into a problem to estimate its time is, for many problems, approximately equal to the time to solve the problem.
Non points-scoring questions: does that happen to you often? Can you give an example? How did you know that the time to estimate would be equivalent to time to implement?
I agree that estimates themselves have a cost/benefit ratio and that sometimes it is going to be negative.
I write in C++. Estimating can require prototyping classes and methods; this IS development, often all that is needed to deploy.
E.g. I'm being asked to estimate the time for an audio-monitoring feature to play a tone when someone speaks yet their voice is muted in the space (Sococo Teamspace has spaces where people work together). The voice-level feature is already in place; its being used by the mic-selection dialog. So the whole estimate involves showing the GUI engineer the API he's already using.
I have to fill out forms online, define the 'feature', time-box development and keep this record up-to-date as the work progresses.
OR I just doorbell Tom and say "Tom, use the same API as the mic-selection dialog". In fact, its taken longer to type this message than the fake work I have to do for this.
So that's a degenerate case. Other cases involve changing timers for idle connection probing (done before the request was finished being uttered); investigating silent-participant overhead (which I did during the sprint planning meeting using netmon on the idle participants in that meeting); aggregate audio packets via our media node to reduce router overhead for bursts of UDP.
That last one is illustrative. To make the estimate I reviewed the media send path for the right place to put in the code (half an hour). Then decided the transport layer was ideal place to aggregate packets using a Nagle timer. I identified 5 cases (idle; aggregate packet under construction; oversize packet; normal packet to aggregate; normal packet that blows the aggregate limit). The constructors for packets need changes to allow header extensions to identify the aggregation boundary for unpacking.
That took a couple of hours. Plus the time to enter the tickets and put in the estimates.
The work will take a few minutes, since I have identified everything that will need to be done. The 'estimation' process has dominated the project time. I can be done with the project before the project manager even notices the tickets I've entered into the database!
SO the whole estimation/recording process is some silly circle-jerk to make management feel involved. IT wasted my time, delayed the project and kept me from doing more useful tasks that our customers could really benefit from.
Btw sorry for my snarky tone above; I was in the middle of this sorry process when I resorted to reading HN/commenting to let off steam.
Wow. I don't take it personally. I gather that your internal process requires all changes to have estimates, regardless of task.
Estimates can be performed multiple times. Conceptually what you've done here is performed 3/4s of the total work (study the change, identify change points, perform basic design) before proceeding to estimate.
You've come across the Cone of Uncertainty in miniature: all that extra work substantially reduced uncertainty and so the estimate range was tiny.
But because of the size of the task, you have a clearly pathological case where estimation had a net negative value. This is a good case of where proceeding directly to the work would have been more effective.
That some estimates will be less accurate due to uncertainty is not by itself a reason to totally abandon estimating.
The generalised case of your argument is that estimation is imperfect in all cases, therefore, we must abandon estimation. This is known as the Nirvana Fallacy: "we have a partial, imperfect solution. Because it is not complete and perfect, it is worthless".
Even modest improvements in estimate accuracy can have enormous value.
By the way, estimating is not planning. An estimate is an estimate. A plan is a plan. They are different things.