[progmanal]

"'How long will that bug take to fix?' is like asking 'How long is it going to take to answer 23 across in next Sunday's crossword puzzle?' It might be fifteen seconds, it might take all day; until I have a chance to look at the puzzle I'm just pulling numbers out of my ass." .

I find this attitude to be a little disingenuous. Obviously every bug cannot be estimated perfectly, but the majority of the time there is some initial data to make a reasonable estimate with a margin of error.

For instance to name a few:

- Past experience with the module associated.

- Whether or not it has been reproduced locally.

- Similarity to other bugs that have come up in the past.

[kabdib]

Depends on the bug, sure.

It's my job [or used to be :-)] to give estimates of bug fix times to management.

It usually broke down to:

- trivial (about an hour)

- nearly trivial (maybe half a day or a day)

- "I have no earthly idea". The last one of these that I fixed involved about twenty people, deep dives into our hypervisor and interprocessor communication mechanisms, research into some hardware details and three 100+ hour weeks about four weeks before we shipped. And we started out not having any idea where in the system the problem was (that took two of those weeks).

[jebblue]

Some or several of the points you raised probably fit more into the "chance to look into the puzzle" phase so that doesn't really stand to reason against his point 100%.

[outsidetheparty]

To be sure. And if we were doing routine maintenance on a longstanding codebase things might be a bit more predictable than they are. But we're trying to do new feature development on a new product, and my experience has been that beyond a very general sense of "this is going to be a big one" vs "this shouldn't take too long, unless I run into something unexpected" -- which is the same level of detail you get with or without Agile -- sizing isn't meaningful enough to be worth the time it takes to do.