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.
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.