Earlier quoted context omitted.
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?…
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.