I've been a professional C, Perl, PHP and Python developer.
I'm an ex-sysadmin from the late 20th century.
These days I do more Javascript and CSS and whatnot, and promote UX and accessibility.
Historical data can tell you how accurate you were with your estimates. But what can it do to help you estimage a new, unknown piece of work?
If you've historically been under by 50% on one and over by 50% on the next, should you assume your next guess is going to be bang on the nose?
Breaking down a project into smaller pieces that you're better at estimating is a good idea, until it takes up more time than doing the work in the first place (which happens). And what you usually get is the transition from one big piece of work you can't estimate into 50 tiny pieces you can and 1 big blob you still can't. That's potentially useful, but...
I think you've named two arguments against making estimations, if I'm reading correctly.
Estimates can't be made from historical data because the historical data varies too widely. (Not clear if you are saying estimates never or just sometimes can't be made from historical data.)
Estimates (sometimes) can't be made because doing so would take longer than the actual task that's being estimated.
I think these are legitimate concerns.
I would respond by saying that, first, valid estimates always incorporate risks, and when risks are included, it means that estimates are in a range from "none of the risks are actualized" (no blockers at all during the project and everything works exactly as planned the first time) to "all of the risks are actualized" (not only does nothing ever work the first time, your company is also sold, or a natural disaster hits your area on top of everything else).
This is important because it addresses the first concern. There's more to the story than "my last two estimates for my last two projects were off by 50% either way so I guess estimates are always off." It means you have to incorporate into your historical data which risks occurred and how exactly they impacted the project.
Again, this is all covered in Demystifying the Black Art.
For the second concern, my impression is that a task that is small enough to execute faster than it can be estimated is obvious to everyone involved so I don't anticipate this happening except in dysfunctional orgs. I think bright, professional people working together on a project will know when to estimate automatically.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Historical data can tell you how accurate you were with your estimates. But what can it do to help you estimage a new, unknown piece of work?
If you've historically been under by 50% on one and over by 50% on the next, should you assume your next guess is going to be bang on the nose?
Breaking down a project into smaller pieces that you're better at estimating is a good idea, until it takes up more time than doing the work in the first place (which happens). And what you usually get is the transition from one big piece of work you can't estimate into 50 tiny pieces you can and 1 big blob you still can't. That's potentially useful, but...
I think you've named two arguments against making estimations, if I'm reading correctly.
Estimates can't be made from historical data because the historical data varies too widely. (Not clear if you are saying estimates never or just sometimes can't be made from historical data.)
Estimates (sometimes) can't be made because doing so would take longer than the actual task that's being estimated.
I think these are legitimate concerns.
I would respond by saying that, first, valid estimates always incorporate risks, and when risks are included, it means that estimates are in a range from "none of the risks are actualized" (no blockers at all during the project and everything works exactly as planned the first time) to "all of the risks are actualized" (not only does nothing ever work the first time, your company is also sold, or a natural disaster hits your area on top of everything else).
This is important because it addresses the first concern. There's more to the story than "my last two estimates for my last two projects were off by 50% either way so I guess estimates are always off." It means you have to incorporate into your historical data which risks occurred and how exactly they impacted the project.
Again, this is all covered in Demystifying the Black Art.
For the second concern, my impression is that a task that is small enough to execute faster than it can be estimated is obvious to everyone involved so I don't anticipate this happening except in dysfunctional orgs. I think bright, professional people working together on a project will know when to estimate automatically.